LNX Kroeg - Deel 2

[HollowGamer]

synoniem schreef op zondag 7 september 2025 @ 10:37:
[...]

Werkt niet meer is een ruim begrip. Hoe heb je mpv geïnstalleerd bijvoorbeeld, standaard repo of snap, of flatpak of zelf gecompileerd en geïnstalleerd?

Dit voelt als die recente drama over de Windows KP dat NVMe deed crashen.

Verder snap ik de obsessie niet zo over Winamp bij veel Linux gebruikers. Er zijn tegenwoordig zoveel betere alternatieven (zowel op KDE + Gnome), helaas zijn er genoeg die deze dan maar draaien op Wine (met lekkende zero-day libs).

Je kunt gewoon de journal checken waarom het niet werkt. Bij mij kwam ik ooit achter een memory probleem, puur omdat mijn editor niet meer goed werkte.

[L0g0ff]

Vishari Beduk schreef op zondag 7 september 2025 @ 10:15:
Tijd voor een rant; mpv werkt niet (meer) op Ubuntu.
Ik heb jarenlang de wens naar zoiets als Winamp op Ubuntu; het aller simpelste programma weermee je mp3-tjes kan afspelen. En ik had hier in dit topic ooit de tip gekregen om mpv te gebruiken. En dat heeft ook lange tijd goed gewerkt. Maar nu weigert mpv.
Anyway de oplossing; aan grok gevraagd een Angular app te schrijven zodat ik mp3 bestanden via de browser kan afspelen. En dat werkt daadwerkelijk. Beetje omslachtig, maar goed.
Maar ik blijf het bijzonder vinden waarom dit anno 2025 nog steeds zo problematisch is.

Is qmmp niet wat je zoekt? Dat zit standaard in je repo.

https://qmmp.ylsoftware.com/

[HollowGamer]

L0g0ff schreef op zondag 7 september 2025 @ 11:19:
[...]

Is qmmp niet wat je zoekt? Dat zit standaard in je repo.

https://qmmp.ylsoftware.com/

Je hebt er nog meer, zoals players met een Winamp skin of preset.

Ik vind het wel gek dat iemand direct mpv gebruikt, zelf vond ik dat niet zo handig, en gebruik ik het liever als backend voor een andere.

[Sjah]

Sinds gister gebruik ik voor mp3's Gapless....strakke GUI.

[Hero of Time]

Audacious heb ik dan weer geïnstalleerd staan. Ik heb ook mpv geïnstalleerd, maar gebruik het eerder voor video's of even snel een mp3'tje spelen, niet hele playlists.

Ik heb voor video's een Haruna geprobeerd, dat maakt gebruik van libmpv. Maar ik kreeg altijd een apart venster waar de video in getoond werd. Alsof het de executable van mpv vindt en die aanroept, ipv het embedded te houden. Voor het 'grote' werk, gewoon series/films kijken, heb ik Kodi. En om met Discord video te delen heb ik VLC, want om een of andere reden kan Discord niet overweg met geluid van Kodi.

[CR2032]

Sjah schreef op zondag 7 september 2025 @ 13:24:
Sinds gister gebruik ik voor mp3's Gapless....strakke GUI.

Zonder GUI werkt anders nog strakker. :_
Kijk eens naar musiccube en persoonlijke favoriet cmus. Zo krachtig en veelzijdig met extenties uit te breiden.

https://www.tecmint.com/install-cmus-music-player-in-linux/

[L0g0ff]

Welke shell gebruiken jullie?

Ik heb een tijdje fish gebruikt. Die is echt super maar omdat ik een aantal keer fouten kreeg in mijn terminal omdat ergens bash niet goed meegegeven was brak er soms iets.

Dus ik ben nu zsh aan het testen. Ik heb er wat plugins in gestopt zodat mijn history, help/man en auto completion een stuk beter werken.

Ik werd gewaarschuwd door een collega dat ik mogelijk ook nu met zsh weer tegen issues aan zou kunnen lopen.

Voor nu vind ik zsh wel even prima. Ik heb wel tmux als default in mijn terminal venster laten starten. Ik had tilix als venster maar die vrat veel te veel onnodige resources. Net wel even mijn muis ook geactiveerd omdat je er automatisch vanuit gaat dat als je ergens op klikt je meteen kan gaan typen. Dat is nu ook zo (om te voorkomen dat ik in het verkeerde venster aan het typen ben).
Ook werkt die muis activatie beter voor tekst selectie. En omdat ik elke keer de tmux shortcuts vergeet heb ik ze rechtsonder als cheatsheet permanent zichtbaar.

Ik ben wel benieuwd hoe jullie hier mee omgaan.

[Vishari Beduk]

synoniem schreef op zondag 7 september 2025 @ 10:37:
[...]
Hoe heb je mpv geïnstalleerd bijvoorbeeld, standaard repo of snap, of flatpak of zelf gecompileerd en geïnstalleerd?

Via de app store.
Maar ja, de Ubuntu app store is eigenlijk net een loterij

HollowGamer schreef op zondag 7 september 2025 @ 11:18:
[...]
Verder snap ik de obsessie niet zo over Winamp bij veel Linux gebruikers.

The unique selling feature was de eenvoud; een replica van een CD speler en niet meer dan dat.

L0g0ff schreef op zondag 7 september 2025 @ 11:19:
[...]
Is qmmp niet wat je zoekt? Dat zit standaard in je repo.
https://qmmp.ylsoftware.com/

Ziet er inderdaad leuk uit. Maar op mijn gnome Ubuntu draait dit niet.
Ook weer via de app store / loterij geinstalleerd maar krijg wayland error. Ook na installie van een wayland plugin niet.

Anyway, ik ga dus toch echt verder met mp3/mp4 via de browser. Dat werkt tenminste
Nu alleen nog even mijn Typescript code een beetje oppoetsen,

[Sjah]

CR2032 schreef op zondag 7 september 2025 @ 17:48:
[...]


Zonder GUI werkt anders nog strakker. :_
Kijk eens naar musiccube en persoonlijke favoriet cmus. Zo krachtig en veelzijdig met extenties uit te breiden.

https://www.tecmint.com/install-cmus-music-player-in-linux/

Heb eerlijk gezegd even op je link gekeken, en helft gelezen... en heb er al geen zin in, zie niet in wat ik ermee moet, die DOS opmaak.. Respect dat je me erop wees, en nu zal je wellicht denken, die kerel is van de suikerkleurtjes van Windows, nou nee hoor.

[ Voor 12% gewijzigd door Sjah op 08-09-2025 22:23 ]

[Hero of Time]

@Vishari Beduk, daarom noemde ik ook nog even Audacious. Die heeft gewoon ondersteuning voor Wayland. Ik heb geen idee of qmmp nog onderhouden wordt.

[RobertMe]

"Bah".

Wil eens gaan experimenteren met Podman i.p.v. Docker, op Debian (Trixie). De online documentatie blijkt al niet geweldig (/afwezig?) te zijn, maar in ieder geval in de man pages beland op de Arch site en die is wel okay. Eerste het beste dat ik probeer: error, "unsupported ..." Dus maar eens zoeken of misschien die "feature" nieuw is, en ja hoor... Zit pas in 5.6 (die ook echt nieuw is, for that matter, 5.6.1 is de nieuwste versie), en Trixie zit nog op 5.4. Dus maar eens packages.debian.org checken, en zelfs sid zit nog op die "oude" versie. Iets van backports zou ik overwegen, uiteraard niet het mixen van verschillende releases.

Bij Docker dacht ik nu juist "waarom gebruik ik de repo van Docker om te installeren en dus altijd de nieuwste versie te hebben dat semi mismatcht met de Debian filosofie". Bij Podman denk ik nu dan weer "waarom hebben ze niet hun eigen repo met de nieuwste versie

Gaat om het gebruik van quadlets. Een spin op systemd unit files waarin je Podman netwerken, volumes, containers, ... kunt vast leggen en "on the fly" worden geconverteerd naar "echte" systemd services (bv voor een container dan een ExecStart=podman run .... op basis van wat in de "quadlet" staat). En wil nu in die file een "setting" gebruiken (InterfaceName in een .network unit) die blijkbaar nog niet bestaat. En die "setting" is "uiteraard" dan gewoon een 1-op-1 mapping naar een podman network create flag (--interface-name). Waarbij de flag wel werkt (getest), en deze kan ik als het goed is ook via PodmanArgs= in de "quadlet" opgeven (nog niet getest, maar deze setting wordt gewoon 1-op-1 overgenomen als zijnde (extra) args). Maar zou natuurlijk mooier zijn als ik gewoon al de "semi bestaande" setting kon gebruiken. En uiteraard beetje ~ meh ~ van Podman maintainers dat ze bij het toevoegen van nieuwe flags (aan podman run, podman network create, podman volume create) niet meteen kijken of die flag niet ook in quadlets ondersteund moet worden (antwoord zal in 99% van de gevallen "ja" zijn). Ook gezien de quadlet code gewoon in dezelfde codebase / hetzelfde project staat.

[Hero of Time]

@RobertMe, och, er is iig een relatief recente versie en er wordt quadlet ondersteund. In Bookworm was de versie net 1 te oud hiervoor. Toen ik op m'n werk juist een machine maakte voor Podman liep ik hier gelijk tegen, heb toen maar met podman-compose en 'podman-generate systemd' een unit gemaakt voor auto-start.

Ik doe praktisch niks met containers, maar de ene container die ik heb draaien (StirlingPDF) doet prima met NAT. Kon toen ik die machine vorige maand een upgrade gaf naar Trixie niet echt vinden wat er allemaal aan opties beschikbaar zijn voor het netwerk.

[RobertMe]

Hero of Time schreef op dinsdag 9 september 2025 @ 20:15:
@RobertMe, och, er is iig een relatief recente versie en er wordt quadlet ondersteund. In Bookworm was de versie net 1 te oud hiervoor.

De versie in Bookworm was zo hip dat een sudo podman system reset mijn volledige OS deed nuken Heb daar toen, 2 jaar terug (denk nog in de RC fase omdat ik toen net een nieuw systeem aan het opzetten was), ook al mee gespeeld. Alleen was dat dus een minder succes doordat hier en daar er wat "incompatibiliteit" / "bugs" met ZFS waren. Zowel Docker als Podman hebben speciale ondersteuning voor ZFS (gehad?), omdat ZFS en overlayfs niet compatible waren. Waarbij zowel Docker als Podman dan maar gebruik maken van ZFS datasets, en specifiek clones, om de layers van de images op elkaar te stapelen (zonder dus alle bestanden dubbel op te slaan / te kopiëren van layer naar layer). Alleen ging er dus "iets" mis bij het verwijderen van de datasets . Waardoor die effectief dus letterlijk alle datasets incl. de "root" verwijderde als ik mij niet vergis.

[HollowGamer]

@RobertMe Ik ben full time Podman Quadlet user, mocht je vragen hebben, dan hoor ik het graag.

Dit is ook mijn probleem met Debian. Voor Docker en Podman kies ik liever iets als CentOS Stream. Dan heb je vrijwel altijd een up to date versie. Bij Debian heb je helaas altijd dit, een reden voor mij het niet meer te gebruiken.

[HollowGamer]

RobertMe schreef op dinsdag 9 september 2025 @ 20:21:
[...]

De versie in Bookworm was zo hip dat een sudo podman system reset mijn volledige OS deed nuken Heb daar toen, 2 jaar terug (denk nog in de RC fase omdat ik toen net een nieuw systeem aan het opzetten was), ook al mee gespeeld. Alleen was dat dus een minder succes doordat hier en daar er wat "incompatibiliteit" / "bugs" met ZFS waren. Zowel Docker als Podman hebben speciale ondersteuning voor ZFS (gehad?), omdat ZFS en overlayfs niet compatible waren. Waarbij zowel Docker als Podman dan maar gebruik maken van ZFS datasets, en specifiek clones, om de layers van de images op elkaar te stapelen (zonder dus alle bestanden dubbel op te slaan / te kopiëren van layer naar layer). Alleen ging er dus "iets" mis bij het verwijderen van de datasets . Waardoor die effectief dus letterlijk alle datasets incl. de "root" verwijderde als ik mij niet vergis.

Dat commando is echt om alles te nuken. Ik raad dat echt nooit aan, tenzij je echt vanaf 0 wilt beginnen. Bedoelde je niet podman system migrate? Die doe je bij een upgrade.

Podman heeft Btrfs als storage driver gehad, maar die wordt vrijwel niet ondersteund. Ze raden aan de default te gebruiken (check ook de tweaks op Arch Wiki over Podman), en vooral niet die driver. Ik wist niet dat er ook een ZFS variant was? Het nadeel is dat deze FS drivers echt een integratie hebben met het OS, en ik dacht ook dat het erg buggy zijn en niet anders te backuppen (don't quote me on that).

[synoniem]

De reden om Debian te gebruiken is stabiliteit. Als je de laatste bleeding edge wil moet je rolling release nemen. Voor productiesystemen gaat stabiliteit boven bleeding edge, voor mijn andere systemen gebruik ik docker om zaken uit te proberen. Podman inclusief de verstrengeling met systemd en andere Red Hat services zijn voor mij daarnaast nog reden om uit die buurt te blijven. En om op te schalen is er k8s wat ook prima werkt.

[HollowGamer]

synoniem schreef op dinsdag 9 september 2025 @ 21:25:
De reden om Debian te gebruiken is stabiliteit. Als je de laatste bleeding edge wil moet je rolling release nemen. Voor productiesystemen gaat stabiliteit boven bleeding edge, voor mijn andere systemen gebruik ik docker om zaken uit te proberen. Podman inclusief de verstrengeling met systemd en andere Red Hat services zijn voor mij daarnaast nog reden om uit die buurt te blijven. En om op te schalen is er k8s wat ook prima werkt.

Ik ben het daar niet mee eens. Het zijn namelijk geen bleeding edge, bij Podman heb je voor die 5.6 release, 5rc's en nog 3 beta's gehad (uit het hoofd).

Debian en hun trage releases, maakt iets niet meer stable. Laatst ook weer een mesa bug, die waren opgelost in de nieuwste, maar dankzij Debian werd hun bug tracker overspoelt met 'stable users' van hun distro, 6 maanden later(!). Waarom was die dan niet gebackport?

Nee, trager is niet stabiel. We moeten daarmee ophouden dat zo te noemen. Het enige is dat slow pace beter is voor Enterprise, vooral die weinig innoveren, that's it.

[ Voor 3% gewijzigd door HollowGamer op 09-09-2025 21:30 ]

[RobertMe]

HollowGamer schreef op dinsdag 9 september 2025 @ 21:17:
[...]

Dat commando is echt om alles te nuken.

Dat is dan ook letterlijk wat die deed. Mijn hele OS verwijderen. En dat kan niet de bedoeling zijn

Ik raad dat echt nooit aan, tenzij je echt vanaf 0 wilt beginnen.

Het was mijn aller eerste trial & error met Podman, dus ja, ik wilde echt vanaf 0 beginnen. Maar niet vanaf 0 in de zin van "insert Debian live USB stick om een hele nieuwe OS installatie te doen".

[RobertMe]

synoniem schreef op dinsdag 9 september 2025 @ 21:25:
De reden om Debian te gebruiken is stabiliteit. Als je de laatste bleeding edge wil moet je rolling release nemen. Voor productiesystemen gaat stabiliteit boven bleeding edge, voor mijn andere systemen gebruik ik docker om zaken uit te proberen.

Het was ook meer een rant. Ik weet hoe Debian werkt en vind dat prima keuzes waar ik mij in kan vinden. Aan de andere kant gebruik ik Arch op mijn desktop Maar op mijn router / servertje / VPS wil ik niet elke X werken mijn vingers kruisen of die na een update nog goed werkt. 1x per ~2 jaar een echte upgrade is wel voldoende. Waarbij Trixie me nu verschillende issues gaf.

Podman inclusief de verstrengeling met systemd en andere Red Hat services zijn voor mij daarnaast nog reden om uit die buurt te blijven.

Tsja, ik vind systemd prima werken, en Podman zie ik ook weinig mis mee. Dan heb ik meer "tegen" Canonical dan tegen Red Hat zeg maar. Kent iemand Mir nog bv? Gevalletje NIH en Canonical denkt het beter te kunnen. systemd is dan wellicht niet perfect, maar wel stukken beter dan de oude init scripts.

En om op te schalen is er k8s wat ook prima werkt.

K8s is dan weer zwaar overkill voor thuisgebruik IMO. Niet alleen qua gebruik, maar ook verbruik. "Schijnt" totaal niet zuinig te zijn.
En wist je dat... je Podman Kube files kunt voeren? En die op basis daarvan ook pods maakt (een concept dat Docker zelf niet echt kent AFAIK).

[RobertMe]

HollowGamer schreef op dinsdag 9 september 2025 @ 21:29:
[...]

Ik ben het daar niet mee eens. Het zijn namelijk geen bleeding edge, bij Podman heb je voor die 5.6 release, 5rc's en nog 3 beta's gehad (uit het hoofd).

En wie test die beta's en RCs? Leuk dat ze er zijn, maar als iedereen een stabiele versie wilt gaat niemand die RCs testen natuurlijk. De laatste keer dat ik in welke vorm dan ook RCs heb gedraaid zijn toch al een hele tijd achter me. En zeker zakelijk zal dat nogal vaak voorkomen (/weinig bedrijven die actief RCs op de pijnbank leggen om feedback te geven).

Debian en hun trage releases, maakt iets niet meer stable. Laatst ook weer een mesa bug, die waren opgelost in de nieuwste, maar dankzij Debian werd hun bug tracker overspoelt met 'stable users' van hun distro, 6 maanden later(!). Waarom was die dan niet gebackport?

Omdat blijkbaar niemand het eerder gemeld had? Of omdat Mesa die bug ook gewoon eerder had kunnen vinden (in een RC bv ). Of omdat de bug alleen optrad met nieuwe hardware die nog niet in het wild geschoten was? En dan zit je weer bij de "Debian moet je niet op gloednieuwe hardware draaien".

Nee, trager is niet stabiel. We moeten daarmee ophouden dat zo te noemen. Het enige is dat slow pace beter is voor Enterprise, vooral die weinig innoveren, that's it.

En daardoor is het dus stabiel Ik weet dat ik zonder gezeik een apt update && apt dist-upgrade kan doen. Van mijn Arch install op de desktop weet ik dat niet (* klopt op hout * Laatste keren dat ik echt issues heb gehad zijn alweer lang geleden. Weken terug wel een AMD firmware blob issue, denk ik, waardoor elke USB-C (monitor) unplug de DRM driver crashte incl. dus KDE Plasma etc etc die wel weer "up" kwamen (/ik had een desktop, incl. crash report scherm van zowel Firefox (geen auto herstart) als KWin (wel auto herstart)).

[L0g0ff]

HollowGamer schreef op dinsdag 9 september 2025 @ 21:29:
[...]
Nee, trager is niet stabiel. We moeten daarmee ophouden dat zo te noemen. Het enige is dat slow pace beter is voor Enterprise, vooral die weinig innoveren, that's it.

Dit is mooi verwoord

Ik denk inderdaad dat je moet kijken naar de "hoofdproces" en daar je OS op af moet stemmen. Als ik ergens een gitlab server wegzet met unattended upgrade aan dan gaat er gewoon Debian op.

Maar wil ik de laatste versie van applicatie x of driver y dan komt er wat anders op.

[HollowGamer]

L0g0ff schreef op woensdag 10 september 2025 @ 07:14:
[...]

Dit is mooi verwoord

Ik denk inderdaad dat je moet kijken naar de "hoofdproces" en daar je OS op af moet stemmen. Als ik ergens een gitlab server wegzet met unattended upgrade aan dan gaat er gewoon Debian op.

Maar wil ik de laatste versie van applicatie x of driver y dan komt er wat anders op.

Precies, je stemt het OS af op de doeleinde.

Ik heb niets tegen Debian, het is bijvoorbeeld super handig voor routers, firewalls, backup-systemen, fileserver, etc.
Als je nieuwere zaken nodig hebt (containers, vm, gpu, etc), dan is in mijn optiek het niet de beste keuze.

Het probleem vind ik dat mensen het daardoor stabieler noemen. Ik twijfel daar erg aan.
Het kan bijvoorbeeld zo zijn dat een corruptie bug opgelost is in een nieuwere kernel, maar helemaal geen backport heeft gekregen op een oudere versie. Ook op software gebiedt speelt dit. Oude software is niet perse beter, mogelijk is nieuwere software zelfs beter door bijvoorbeeld een nieuwere backend t.o.v. de vorige.

Als we Arch Linux bleeding edge noemen, dan vind ik ook dat Debian slow pace mag worden genoemd.

[RobertMe]

HollowGamer schreef op woensdag 10 september 2025 @ 17:25:
Als je nieuwere zaken nodig hebt (containers, vm, gpu, etc), dan is in mijn optiek het niet de beste keuze.

Waarom zijn containers nieuwe zaken? Docker & K8s bestaaan misschien al 10+ jaar? En ik heb ook niet het idee dat daar nog heel grote ontwikkeling in zit. Hoogstens dat er een nieuwe container runtime komt (Podman bv ) die wel nog meer ontwikkeld wordt. Maar een 10 jaar oud Docker image kun je nog steeds draaien op een moderne runtime en een hypermodern image die je vandaag build met Podman / Buildah kun je waarschijnlijk ook draaien op een 10 jaar oude Docker versie.
Dat is juist het hele idee van het hele container verhaal.

Ik heb zelf in ieder geval nog nooit problemen gehad met "nieuwe" containers / images op een oude Debian versie. Maar draai dan wel Docker op de Docker officiële manier, hun eigen repo dus

En ik denk zelfs dat velen niet eens op de hoogte zijn van Docker Compose vs de veel modernere Compose plugin. Dat bv het compose file format intussen een officiële standaard is en ook op andere runtimes werkt etc. Want het is voor 99% nog gewoon hetzelfde format als docker compose v2 die ook alweer vele jaren oud is. Hence "vrijwel geen grote ontwikkelingen" op gebruikersvlak.

[synoniem]

Ja het gebruik van de Docker repo is wel een vereiste als je onder Debian docker containers wil draaien. En zoals gezegd voor containers in productieomgevingen kun je nog beter k8s gebruiken

[HollowGamer]

RobertMe schreef op woensdag 10 september 2025 @ 17:52:
[...]

Waarom zijn containers nieuwe zaken? Docker & K8s bestaaan misschien al 10+ jaar? En ik heb ook niet het idee dat daar nog heel grote ontwikkeling in zit. Hoogstens dat er een nieuwe container runtime komt (Podman bv ) die wel nog meer ontwikkeld wordt. Maar een 10 jaar oud Docker image kun je nog steeds draaien op een moderne runtime en een hypermodern image die je vandaag build met Podman / Buildah kun je waarschijnlijk ook draaien op een 10 jaar oude Docker versie.
Dat is juist het hele idee van het hele container verhaal.

Ik heb zelf in ieder geval nog nooit problemen gehad met "nieuwe" containers / images op een oude Debian versie. Maar draai dan wel Docker op de Docker officiële manier, hun eigen repo dus

En ik denk zelfs dat velen niet eens op de hoogte zijn van Docker Compose vs de veel modernere Compose plugin. Dat bv het compose file format intussen een officiële standaard is en ook op andere runtimes werkt etc. Want het is voor 99% nog gewoon hetzelfde format als docker compose v2 die ook alweer vele jaren oud is. Hence "vrijwel geen grote ontwikkelingen" op gebruikersvlak.

Ik bedoel dat de engines heel vaak achterlopen op de distro.

De enige manier is om een PPA te toe te voegen, maar dat brengt ook wel weer risicos met zich mee.

[RobertMe]

synoniem schreef op woensdag 10 september 2025 @ 20:11:
Ja het gebruik van de Docker repo is wel een vereiste als je onder Debian docker containers wil draaien.

HollowGamer schreef op woensdag 10 september 2025 @ 20:21:
[...]

Ik bedoel dat de engines heel vaak achterlopen op de distro.

De enige manier is om een PPA te toe te voegen, maar dat brengt ook wel weer risicos met zich mee.

Ik zou echt bij god niet weten wat er de afgelopen twee jaar veranderd is aan Docker waardoor ik in ieder geval nu bij Trixie niet de Debian versie zou kunnen gebruiken. Dit dus nadat ik nu (nog steeds) wel de Docker repo gebruik. Maar die repo draai ik al vanaf een van de bookworm RCs (toevallig toen het systeem op gezet). En als ik niet weet wat er in die periode veranderd zou zijn / nieuw is dan zal ik vast niks missen met een versie die dus zeg een half jaar oud is.

En dat idee heb ik dus eigenlijk al veel langer v.w.b. Docker. Enige dat ik van de updates merk is dat op een gegeven moment na een update de mac adressen van (sommige?) containers gewijzigd waren en dat vonden mijn firewall regels minder. (Containers die internet toegang moesten hebben hadden dat niet meer). Reden dat ik MAC adressen gebruik is omdat die natuurlijk IP v4 / v6 onafhankelijk zijn.