Docker zet streep door oud gratis lidmaatschap Docker Free Teams

Het bedrijf Docker gaat een van zijn lidmaatschapsvormen verwijderen. Gebruikers in die vorm kunnen dan niet meer bij hun data, behalve als ze een betaald lidmaatschap nemen. Eerst leken ook images verwijderd te worden, maar daar kwam het bedrijf later op terug.

Het gaat om het Docker Free Teams-lidmaatschap. Zoals de naam doet vermoeden, is het gekenmerkt door toegang voor meerdere auteurs en het feit dat het gratis is. Dit lidmaatschap is al langer niet beschikbaar voor nieuwe Docker-gebruikers; alleen gebruikers die het al hadden voordat het afgeschaft werd, worden nu dus getroffen. De deadline voor de migratie is 13 april.

In de aanvankelijke communicatie werd gesteld dat 'organisatiedata' van teams met dit lidmaatschap na 30 dagen verwijderd zou worden. Later kwam het bedrijf daarop terug en verduidelijkte het dat die data verwijderd wordt, maar dat de images met rust gelaten worden. Gebruikers op Hacker News komen met het kritiekpunt dat de 'latest'-tag hiermee nutteloos en gevaarlijk wordt; als het ontwikkelteam niet over kan naar een ander lidmaatschap, dan krijgen de images geen updates meer en veroudert latest vanzelf.

Docker zegt dat deze teams wellicht over kunnen naar Docker-Sponsored Open Source, ofwel DSOS. Daarbij krijgen de teams een jaar gratis het Docker Team-abonnement, maar mogen ze nooit hun software monetiseren. Alleen donaties voor lopende kosten zijn toegestaan. Lidmaatschappen omzetten naar een ander abonnement kan ook, maar het Team-lidmaatschap kost minimaal 300 dollar per jaar. Naar een gratis lidmaatschap met minder mogelijkheden migreren, kan mogelijk ook; Docker zegt dat gebruikers daarvoor een supportticket aan moeten maken.

Zowel gebruikers als ontwikkelaars die repo's bij Docker onderhouden, zijn niet blij met het nieuws. Ontwikkelaars zeggen in een moeilijke situatie geplaatst te worden, vanwege hun images, maar ook de images van anderen waar zij weer op vertrouwen. Gebruikers lopen risico, doordat images waar zij gebruik van maken, ineens stil zouden kunnen vallen als de ontwikkelaar niet met succes kan uitwijken. En als de developer uitwijkt naar bijvoorbeeld Githubs Container Registry, dan moet nog steeds de url van de image aangepast worden, wat ook vergt dat de eindgebruiker op de hoogte gesteld wordt.

Docker stelt in een update van zijn bekendmaking dat 'slechts twee procent van de gebruikers hierdoor getroffen wordt', maar dat gaat vermoedelijk over twee procent van de ontwikkelaars die repo's van Docker gebruiken en niet twee procent van alle Docker-gebruikers, inclusief clients die alleen images ophalen. Images van twee procent van repo-onderhouders kunnen alsnog te maken hebben met ontzettend veel pulls.

De kwestie wordt onder andere besproken in twee posts op Hacker News, een blogpost van een prominent lid van de Docker-gemeenschap, een artikel op DevClass en een GitHub-issue. Dockers aanvankelijke bekendmaking betrof een e-mail die verwees naar een pdf, maar er is ook een aanvullende bekendmaking gedaan. De pdf is tussendoor van updates voorzien, waardoor commentaar op het handelen van Docker achterhaald kan lijken.

Docker is een platform waar ontwikkelaars software-images kunnen hosten, die gebruikers in containers draaien. Het usp van dit systeem is dat de nodige dependencies voor de software die verspreid wordt, gebundeld kunnen worden in de images. Zo kan zelfs ook software die oorspronkelijk voor een ander besturingssysteem ontwikkeld is, op door Docker ondersteunde platformen draaien.

Reacties (79)

Toch maar even uitzoeken of ik makkelijk al mijn container images zelf kan bouwen, de hele keten, en in mijn eigen registries kan zetten.

Zo heel lastig is het niet, gewoon Gitea draaien, Drone of Woodpecker er langs, en dan en je er al.
Docker zelf is niks mis mee, maar de Hub en alle andere rommel die ze hebben moet je gewoon proberen te vermijden. Vrijwel alle belangrijke images die op de Docker Hub staan hebben ook een GitHub linkje met daarin de Dockerfile en alle andere bestanden die gebruikt worden, en soms zelfs een CI config die je zo kunt gebruiken

Docker zelf is niks mis mee

Nou, Docker Desktop is anders als applicatie aardig een gedrocht te worden.

Met ook nog venijnige licensering, waardoor het niet zomaar op iedere werklaptop te installeren valt.

Waarom zou je Docker Desktop gebruiken? Je krijgt dezelfde functionaliteit als je Docker gewoon zonder de desktop UI draait, dev omgevingen kun je oplossen met bijv Telebit ofzo.

Qua licentie valt het wel mee tenzij je voor een grote organisatie werkt, en in dat geval mogen ze netjes betalen

Omdat je voor docker zelf Linux nodig hebt. Op Windows en Mac ontkom je niet echt aan docker desktop dat daar een VM voor opzet.

Op Windows heb je natuurlijk ook nog WSL2 maar dat is ook niet echt een geweldige oplossing.

Docker Desktop gebruikt standaard ook gewoon WSL2, dus je kunt net zo goed zelf WSL2 installeren en gebruiken.

Hyper-V is alleen interessant als je Windows containers gaat draaien, maar die zijn er niet zo heel veel

Maar docker desktop zet dan wel weer propere netwerk interfaces op in windows om altijd probleemloos via wsl2 te functioneren.
Een custom docker installatie in WSL2 zelf combineren met een corporate VPN is bijvoorbeeld een horror ervaring die docker desktop voor je oplost.

Dat is ook onzin, je kunt gewoon een VPN container in je stack gooien, ook binnen WSL2, en je netwerk via die container verbinden met een ander.

Maar het heeft sowieso mijn voorkeur om Docker niet op mijn laptop te draaien, ik dan moet de werkgever maar een Azure of AWS abonnementje afnemen en daar een VM voor Docker beschikbaar stellen.

Ja het kan.

Maar even serieus. Ik heb vanuit interesse ook geprobeerd om netjes een docker en k8s omgeving op te zetten zonder docker desktop, maar dat is echt veel meer werk.

Ik ben het met je eens dat die licensing stap van hun wel een smerige was, maar aan de andere kant moet er ook gewoon geld verdient worden en leveren ze wel gewoon een goede, simpele service voor dat geld.

Geen gedoe met minikube settings die je moet configureren, geen geode met WSL integratie, alles onder 1 dak (docker en K8s) best wel prima update beleid, automated setup via chocolatey.

Ff alle gekheid op een stokje. Voor organisaties is het de licentie wel waard. Voor thuisgebruik is het een ander verhaal, maar daar is nu nog geen licentie voor.

Leuke ontwikkelaar ben je dan.

Ik ontwikkel software naar weiger containers te draaien haha

@deze moest onder @Oon

[Reactie gewijzigd door DutchKevv op 18 maart 2023 11:20]

Ik weiger absoluut niet om containers te draaien, maar ik doe dat liever remote. Vrijwel alle development tools hebben de optie om met een remote docker machine te verbinden, en het is nou niet dat mijn werklaptop 48 cores en 64GB geheugen heeft.

Dus ik laat het verwerken van grote hoeveelheden data lekker gebeuren op een server die daar voor gemaakt is, en gebruik mijn laptop voor het ontwikkelen zelf

Hoezo is dat niet ideaal? Ik heb docker met WSL2 op mijn windows machine geinstalleerd, lijkt goed te werken,

Nou ja, je kunt het gewoon zonder desktop installeren:

Terminal: https://formulae.brew.sh/formula/docker (brew install docker)
De app: https://formulae.brew.sh/cask/docker#default (brew install --cask docker)

Heb je al eens naar podman-desktop gekeken?

Nexus kan je ook als docker+maven+rpm+npm repo gebruiken.

Meestal is dat een fluitje van een cent, tenzij je op langzame hardware draait

Verwacht overigens dat nagenoeg alle opensource packages nu gaan overstappen naar GitHub’s container registry

Of GitLab. Mogelijkheden genoeg.

GitLab kan ook zeker en is een mooi product, het mist wel een beetje de opensource community van het formaat dat wel op Github aanwezig is vandaar dat ik Github noemde

Het grote nadeel van GitHub is dat GitHub actions extreem traag zijn als je in het gratis plan zit zonder eigen build server.

Waarmee ervaar je trage builds? Ik herken dat helemaal niet. Heb je er misschien een voorbeeld van?

Ja, ik heb een wasm blazor applicatie met MudBlazor en nog een aantal NuGets.
De optimalizatie stap kost inmiddels een uur, terwijl het lokaal minuten duurt.

De repository zelf staat private.

[Reactie gewijzigd door Kriekel op 17 maart 2023 19:28]

Waarop is ie traag san? Nuget restore kun je gewoon cachen.

Beetje late reactie, maar op het optimaliseren van de js, zodat deze zo klein mogelijk is.

#17 14.56 Optimizing assemblies for size may change the behavior of the app. Be sure to test after publishing. See: https://aka.ms/dotnet-illink
#17 14.57 Optimizing assemblies for size. This process might take a while.
#17 1835.3 Compressing Blazor WebAssembly publish artifacts. This may take a while...

Het antwoord is ja. Je kunt ze in AWS zetten of bij andere cloud providers (images registries zijn echt goedkoop) en anders zelf een nexus repo neerzetten bij je thuis.

Gewoon een docker image die je dan.. oh wacht

I lol'ed

Een eigen registry opzetten kan al met de docker image registry. Maar mijn publiek beschikbare images staan inmiddels ook op Github inclusief CI om de container automatisch te genereren bij iedere wijziging en voor meerdere architecturen. In de praktijk betekent dit dat ik geen nieuwe containers en images meer publiceer op Docker Hub.

Het nadeel is de base-images, dus debian/alpine/ubuntu/windows etc, die komen vrijwel altijd bij de docker hub vandaan en die kun je niet heel eenvoudig zelf bouwen. Het kan wel, maar de maintenance is dan wel een stuk groter.

Ik gebruik al jaren https://quay.io/, is meer feature rich dan de Docker variant en tot zover gratis.

github.com kan het makelijk

Heeft dit impact op gebruikers van software die images van docker halen? Bijvoorbeeld in mijn synology heb ik docker. Heeft dit impact op het installeren van nieuwe zaken of het algemeen gebruik?

Zou ik ook wel willen weten. Kan me voorstellen van wel als de makers hun images niet meer kunnen plaatsen. Heb ik net alles overgezet op Docker, kan ik weer terug naar VMs

Waarom weer terug naar vm's?
Als je vm's maakt, kan je ook containers maken.

En Docker is niet het enige container formaat. Gebruik je een product als ProxMox, dan kun je zowel VMs als containers (LXC) tegelijkertijd draaien en/of creeeren en/of beheren. Al dan niet in de vorm van een template, waarmee automatische deployment van VM's/containers (naar gelang wat je nodig hebt) ook niet al te moeilijk is.

Docker is een bruikbare oplossing. Maar het verre van de enige oplossing. Anderen zijn minder venijnig dan wat Docker met deze stap laat zien.

Maar dan niet meer voor gratis, toch? VM is ISO laaien en installeren 🤷🏻‍♂️

Waarom zou het niet meer gratis kunnen, er zijn meer repositories naast Docker hub.

Ik ben alleen bekend met Docker Hub, maar ben verre van een expert. Ik zie nu echter dat er ook andere repositories zijn, weer wat geleerd. Nou dan zal het wel loslopen. Eerst maar eens kijken wat 13 april brengt dan.

Je hebt in principe niet eens een repository nodig, je kunt een image ook zippen en als domme download aanbieden.

Voorbeeldje? Neem toch aan dat als ik bijv. Domoticz in Docker wil draaien, toch het nodige ergens vandaan moet halen? Het gaat hier om persoonlijk gebruik trouwens hè, ik ga geen eigen images aanbieden of zo.

docker load < domoticz.tar.gz

Die je dan gewoon ergens gedownload hebt.

Wellicht voor alle duidelijkheid: dit artikel gaat over de aanbieders van images. Die hebben dus ook de optie om hum image als .tar.gz aan te bieden.

Ah zo, dat is dus niet van toepassing voor mij, maar het zou wel fijn zijn als veel gebruikte projecten (bijv. Domoticz, Unbound, Pi-hole) blijven werken. Benieuwd hoe dat zal gaan.

Edit: kennelijk heeft dit geen invloed op Domoticz, aldus de ontwikkelaar. Nou weet ik natuurljk niet of deze een betaalde variant heeft.

[Reactie gewijzigd door vespino op 17 maart 2023 17:31]

Het probleem voor de gebruikers is dat veel gratis projecten hun images niet meer kunnen updaten zonder te betalen voor docker. Daardoor zullen veel bugs en vulnerabilities niet meer gefixt kunnen worden.

Op https://www.docker.com/pricing/ zie ik nog steeds 'personal' staan. Blijft dat gratis?

Aan de andere kant, in de documentatie zie ik verwijzingen naar https://www.docker.com/community/open-source/application/. Daarmee kan je voor opensource zaken 'sponsoring' krijgen van docker. Of je dan pro, team of business krijgt of dat ze hier een ander aanbod achter hebben is altijd te zien. Ook heb ik niet naar de detail eisen gekeken. Wel wordt alles open...

Tja het moest eens gebeuren. Docker is natuurlijk handing omdat alles op lagen is gebouwd, maar daar lever je dus in op basis van opslagruimte. Blijkbaar gaat dat echt om gigantische hoeveelheden, maar ook in transit verkeer. Zo iets kost gewoon veel geld.

Het probleem van afhankelijkheden binnen een systeem is letterlijk verplaatst door de abstractie d.m.v. 'layering'. VM's zijn/waren 'bloated'. Maar blijkbaar toch niet zo'n gek idee. Ik hou het wel lekker KISS.

Er is een mooie mitigatie geschreven door Tim Perry (van HTTP Toolkit).

Het probleem: de Docker-toolset maakt gebruik van een niet aan te passen alias die verwijst naar hun eigen registry (de plek waar mensen hun images uploaden). Dus als een gebruiker typt (zoals in een tutorial vermeld):

docker pull project-foo/image-bar

Dan wordt er eigenlijk verbonden met de officiële Docker Hub:

docker pull registry.hub.docker.com/_/project-foo/image-bar

En er is in de officiële Docker-toolset geen manier om dit aan te passen. Hoewel, je kunt een mirror instellen, maar dat vereist configuratie bij elke installatie (en die is niet altijd benaderbaar, zoals in CI-systemen).

Echter: zelf images hosten is duur. Het gaat vaak om erg veel data (al snel honderden MB's, bij populaire projecten duizenden keren per uur gedownload), je hebt een extra server te beheren, en voor veel projecten is dat nu eenmaal niet betaalbaar noch deel van de core business.

Dus dan wil je je images elders hosten, maar wel flexibel blijven. Want als je nu alles bij GitHub stalt, en al je tutorials aanpast naar "docker pull ghcr.io/project-foo/image-bar", en volgend jaar past ineens GitHub hun voorwaarden aan, dan moet je weer alles overal updaten.

Daarnaast blijven je gebruikers op een dood spoor: de originele image-identifier blijft onthouden, terwijl daar geen nieuwe images meer naar gepusht worden.

De oplossing:

1. Zorg voor een subdomein, bijvoorbeeld docker.jouwopensource.org
2. Draai hier een minimale redirect-tool op die Docker-verzoeken doorstuurt naar jouw huidige Docker-registry
3. ???
4. Non-profit!

Dan kun je alle tutorials, Dockerfiles, enzovoorts aanpassen naar "docker pull docker.jouwopensource.org/foo-project/bar-image", en als je in de toekomst van host verandert, hoef je als projectbeheerder alleen je redirects aan te passen!

[Reactie gewijzigd door CodeCaster op 17 maart 2023 16:25]

Azure Container Registry is een prima alternatief, met ook ondersteuning van docker build en docker buildx (multi-platform images) die async een opdracht kunnen krijgen.

Wordt Podman al als een volwaardig alternatief beschouwd?

Podman is de runtime, niet de registry om images te hosten.
Podman is zover ik weet een redelijk alternatief, maar zaken als Docker Swarm (services met overlay networks over meerdere hosts) zijn niet supported. Maar daar heb je tegenwoordig Kubernetes voor.

Kubernetes is wel weer een heel ander beest dan Docker Swarm. Docker Swarm is een kwestie van een swarm maken of joinen met één commando, een docker-compose draaien en er worden 'gewone' Docker containers gedraaid.
K8s draait uiteindelijk gewone containers, maar is toch heel wat meer werk om op te zetten en m.i. een stuk minder transparant

Ik begrijp je punt, maar dat valt tegenwoordig echt wel mee.

Met implementaties zoals k3s, kan je ook met 1 commando een cluster maken en/of joinen.

Daarnaast kan je met "kompose convert" een docker compose file omzetten voor deployment op Kubernetes.

Overigens kan ik bovenstaande sterk aanraden, Kubernetes is niet voor niets de nr 1. container orchestrator momenteel.

Ja mee eens hoor dat k8s veel complexer is, maar ik zie om mij heen het gebruik van Docker Swarm sterk afnemen. K8s as a service heb je in alle grote clouds wel, dan valt dat meerwerk wel meer mee.
Toch wel jammer dat er geen drop-in replacement voor Docker Swarm is vooralsnog.

Docker Swarm is al een aantal jaren op weg naar buiten, ik verbaas me er dan ook over dat er nog niet echt een 1:1 alternatief is.

Ik host alles lokaal op één node, gebruik Swarm dan ook vooral voor het makkelijk bij elkaar houden van spullen. K8s kan dat in principe ook, maar daar is toch wel echt significant meer inspanning voor nodig om dat de eerste keer op te zetten helaas.

Maar wie weet, misschien zet deze opnieuw vreemde actie van Docker iemand er op aan om wel een echt alternatief voor Swarm te maken. Zou wel mooi zijn

Als je alles op één node hebt staan, is het dan niet makkelijker om gebruik te maken van standaard docker i.c.m. iets als portainer?

Daarbij mis je de mogelijkheid om stacks te maken.
Portainer had ik ook draaien, maar dat is ook weer zo'n draak van een tool waarvan je een groot deel niet eens gebruikt in zo'n setup.

Daarnaast is het ook fijn dat ik mijn zelfde setup ook 1:1 kan gebruiken als ik ooit wél een cluster heb, het is wel zo handig om dan dezelfde principes toe te kunnen passen en zelfs dezelfde docker-compose bestanden die ik al heb.

Je hoeft Docker niet in swarm te draaien om compose te gebruiken.
Ik heb +30 stacks op 1 host en gebruik daarom niet Docker in swarm.

Volledig mee eens. Persoonlijk ben ik ook bij Kubernetes blijven hangen. Zelf hosten gaat tegenwoordig ook stukken makkelijker.

Om de installatie-/configuratie-hel een beetje te vermijden ben ik K3S gaan gebruiken.Tot nu toe met volle tevredenheid.

Installatie is een one-liner*

curl -sfL https://get.k3s.io | sh -

En nieuwe nodes laten joinen ook

curl -sfL https://get.k3s.io | K3S_URL=https://myserver:6443 K3S_TOKEN=mynodetoken sh -

edit:
(*Ik verwacht elk moment een preek over het uitvoeren van remote-code in je shell, maar laten we die achterwege halen vandaag )

Wordt Podman al als een volwaardig alternatief beschouwd?

Kevin Degeling voor Fedora Magazine, Docker and Fedora 37: Migrating to Podman:

Podman was certainly not the first on the scene, and it has been fighting an uphill battle. Still, in many ways, this has been an opportunity. Podman can avoid some of the architectural errors that Docker made, and it can integrate with other tools that didn’t exist yet when Docker started.

Als je een goed inzicht wil krijgen in wat voor een grove trap in het kruis van de OSS-community dit is, raad ik aan om deze toelichting [1] en community-reacties [2] te lezen.

[1] https://blog.alexellis.io...eting-open-source-images/
[2] https://github.com/docker/hub-feedback/issues/2314

Voor niets gaat de zon op. Als je werkt met de producten van een SaaS bedrijf moet je altijd rekening houden met het feit dat het kan ophouden. Kun je hoog of laag springen, maar een bedrijf als docker mag zijn eigen voorwaarden bepalen.

En ze hebben alternatieven. DSOS word genoemd. En voor grote projecten is er mogelijk wel iets te onderhandelen, dat is goede reclame.

Een "OSS-community" zijn geeft je niet ineens rechten op iets.

Ik vind het jammer, zeker daar het om maar heel weinig groepen lijkt te gaan. Laat die dan lekker. Maar dat is niet mijn keuze, maar die van docker.

Kort door de bocht. Docker had niet kunnen bestaan als de OSS-community niet bestond. Als je product vervolgens een hoeksteen van de moderne digitale infrastructuur vormt heb je gewoon een corporate responsibility om daar zorgvuldig mee om te springen. Ze mogen best besluiten dat het geen eeuwig houdbare situatie is, waar overigens over te twisten valt, maar dan dien je ook met een plan van aanpak te komen dat de status quo niet dramatisch in gevaar brengt. Met name de oorspronkelijke plannen was dat totaal niet het geval, en dat spreekt boekdelen over hoe ze tegen hun rol in het systeem aankijken.

Wat betreft DSOS: er zijn voldoende voorbeelden te vinden op wat voor manieren dit programma tekort schiet.

Strikt genomen heb je inderdaad geen rechten als OSS-community. Als dat de algemene tendens in de softwarebranch als geheel gaat worden zijn we echter het haasje. Juist de mate van openheid en vrijheid geeft je als organisatie een morele plicht om er aan terug te geven als jouw product gestoeld is op andermans werk. Dit is gewoon een fundamentele factor in het succes van de softwarewereld.

Docker had niet kunnen bestaan als de OSS-community niet bestond.

Is dat zo? Ik ken de hele geschiedenis niet, maar Docker Inc staat als developer voor docker. De software is onder een apache licentie en iedereen kan een nieuwe "docker.com" starten. Je kunt ook docker containers bij microsoft en anderen hosten. Niets bind je aan docker.com. Misschien is het meer dat de OSS community blij mag zijn dat het zo lang gratis is geweest. Welke kant die balans hangt is wat mij betreft afhankelijk van wie de major contributers van de docker software zijn geweest. En het algemene product is nog steeds open en gratis. Deze hele discussie loopt rond de extra features.

Ze zullen het eerste bedrijf niet zijn dat de OSS community waar ze hun bestaan aan danken voor het hoofd stoten en kapot gaan, maar dat moet dat bedrijf weten. De OSS community kan gewoon docker elders doen en verder ontwikkelen. Dat is eerder voor grote projecten gebeurd en kan hier ook als het nodig is. Docker.com is niet onvervangbaar. Dat is juist de kracht van OSS, niet happy, begin elder opnieuw.

corporate responsibilty? Tja ze developen nog steeds aan docker. Ik denk niet dat het erg is dat ze wat geld voor de extra's vragen, dat is hun keuze. Het idee dat je op de "goedheid" van een bedrijf rekent komt op zijn minst niet slim over.

[Reactie gewijzigd door bzuidgeest op 17 maart 2023 16:46]

Zeer interessant maar als leek snap ik niet alle nuances van de gevolgen even goed. Jouw post zou een +3 waard zijn als je dat zou kunnen samenvatten.

Zo lijkt het voor mij alsof iemand die zijn open source project aanbiedt als docker image nu ineens zal moeten betalen? Als dat waar is dan is dat een serieuze streep door de rekening van velen.

Ik vraag me oprecht af waarom ik de moeite neem om een uitgebreid artikel te schrijven als reageerders met een +2 beloond worden voor het plaatsen van links gaan plaatsen die van meet af aan al in het artikel staan.

E: klagen over moderatie mag niet, ook niet door crew. Fix'd.

[Reactie gewijzigd door Mark_88 op 17 maart 2023 13:58]

Wat boeit jou die score van een reactie als auteur??

Omdat je ervoor betaald wordt Mark ;-)

Maar ik heb speciaal voor jou mijn moderatie rechten weer aangezet, want een beetje suf is het wel ja.

Ik had zelf die laatste alinea graag als tweede gezien trouwens.

[Reactie gewijzigd door Gutser op 17 maart 2023 13:44]

Tweakers auteur vraagt zich meteen oprecht af waarom hij schrijft na het lezen van 1 reactie die hem niet aanstaat.

Niet bepaald professioneel.
Tweakers reacties worden steeds zuurder...

Bleef het maar bij een keer.

Denk heel even na over hoe je nu overkomt.

Zeurderig ipv professioneel. Zuur ipv professioneel.

Stap even weg vd computer zou ik zeggen. Je word betaald om tweakers te vertegenwoordigen, en de manier waarop je dat nu doet is alles behalve positief of normaal.

Ik denk een goed idee om de volgende keer bij de links wellicht enige duiding te plaatsen. Dat er door anderen ook over geschreven wordt is voor mij geen incentive om de link te openen. Zeker niet als het 5 links zonder duiding in een enkele zin betreft. Die duiding is er wel in de reacties. Het gaat dus niet slechts om de links.

Daarnaast, ik snap dat aan het einde van de week het lontje wellicht wat korter is, maar ik vind de manier waarop je reageert niet bepaald kies.

Het doorstrepen van de text is niet weghalen van de text lol. Als niet crewlid krijg je daar gewoon een moderatie ban voor

Dan kun je de relevantie zien van eerdere reacties.

Zou in de opmaak kunnen zitten, niet iedereen triggerd op linked tekst vermoed ik, bij een dergelijke verwijzing verwacht het brein van sommigen misschien links zoals bij de opmerking van Sandos hierboven.

Ik zal kleur bekennen: omdat ik hier al aardig op ingelezen ben als getroffen gebruiker heb ik het artikel vluchtig doorgenomen en de links volledig gemist

Ik heb het nog eens aandachtig gelezen en je hebt een goede uitwijding geschreven. Er zijn echter twee cruciale onderdelen die wel meer toelichting hadden verdiend:

• Het risico op cybersquatting, die inmiddels enigszins verminderd is door de belofte dat namespaces nooit meer vrijkomen. Het advies blijft om dit zelf te mitigeren met een free account omdat Docker hiermee wel aantoont dat er niet op gerekend kan worden dat ze dit beleid eeuwigdurend gaan hanteren.
• Het DSOS-programma laat flink te wensen over met gerapporteerde wachttijden van meer dan een jaar en nul communicatie (die in sommige gevallen al werd afgehandeld door een stagiar(e).

Maar wat is er dan wél informatief (= +2) aan jou post?

Je moet gewoon niet klagen over het brakke moderatiesysteem.

Iedereen weet al jaren dat het niet goed is en vooral ook niet (goed) werkt. Uiteraard zijn er uitzonderingen dat het goed gaat.

De denkbeeldige punten zijn het probleem niet. Wel dat de reageerder en de beoordelaars evident het artikel niet goed hebben gelezen. Dat moedigt niet aan tot schrijven met oog voor detail en een streven naar volledigheid.

Wel, maar ik ben niet heel erg geneigd om de links te volgen die jij plaatst. Een referentielijst is veel duidelijker dan maar woorden in het artikel in een link te veranderen.

Ik kan me je reactie voorstellen. Overigens vind ik die hele rating nergens op slaan. Zo vaak zie je dat het niks te maken heeft met waar het voor bedoeld is (relevant, informatief, etc.), maar is het of iemand het er mee eens is met een mening. Het heeft meer te maken dan met het juichen bij een sportwedstrijd ofzo.

Een interessant self-hosted alternatief is Project Quay. Niet te verwarren met het commerciële alternatief Quay.

edit:

Je kan ook één gratis repository bij DigitalOcean (500mb) aanvragen.

[Reactie gewijzigd door Redsandro op 17 maart 2023 18:25]

Ook kun je tegenwoordig Docker repositories (en vele anderen) bij je eigen Gitea en Gitlab instances kwijt.

Moet zeggen dat dit met Gitea bijvoorbeeld erg goed werkt, ook met multi-arch images. Maar ook met bijv. composer packages en noem maar op