GitLab wil inactieve projecten bij gratis gebruikers na een jaar verwijderen

GitLab wil projecten van gratis gebruikers die een jaar niet aangeroerd zijn, vanaf september automatisch verwijderen. Met deze maatregel wil het DevOps-platform de hostingkosten met 25 procent terugdringen. Projecten van betalende gebruikers worden niet geraakt.

Volgens bronnen die de redactie van The Register kon spreken zijn dergelijke inactieve projecten goed voor een vierde van de hostingkosten van GitLab en kan het DevOps-platform jaarlijks 1 miljoen dollar besparen door deze te verwijderen.

Gratis gebruikers van onaangeroerde projecten die in aanmerking komen, zullen maanden en weken op voorhand verwittigd worden, al kon The Register geen concrete termijnen meegeven. Het wordt naar verluidt wel mogelijk om de timer van een jaar te resetten door een opmerking te plaatsen bij een project of een aanpassing te doen. Volgens The Register gaat de maatregel vanaf september van kracht; een exacte datum is niet bekend.

Door Jay Stout

Redacteur

04-08-2022 • 18:30

127

Submitter: Chaseream

Reacties (127)

127
127
87
11
0
28
Wijzig sortering
Omdat Gitlab open source is kun je het ook zelf hosten. Maar ook een andere partij kan het voor jou doen. Wat alternatieven:

[Reactie gewijzigd door scholtnp op 28 juli 2024 21:22]

Ik kan Codeberg erg aanraden, maar dat draait op een aangepaste Gitea (https://gitea.io/en-us/), niet Gitlab
Gitea is sowieso een dikke aanrader! Ik gebruikte het al privé, maar zakelijk zijn we nu ook over op Gitea na veel gestoei met Gitlab EE.

De grootste van Gitea voordelen zijn uptime, snelheid en simpliciteit. Gitlab is traag, groot, log, lastig te beheren en in veel gevallen gewoon overkill. Ik snap dat je Gitlab gebruikt bij een grote organisatie, maar voor de gemiddelde ontwikkelclub volstaat Gitea gewoon.

CI/CD gaan we overigens met Woodpecker CI doen.
Woodpecker CI nooit van gehoord, wel nieuwsgierig hoe dit werkt.
Vooral de recente versie 1.17, waar je nu zowel docker images als NPM packages kan plaatsen. :)
Ik denk dat ik wel weet waarom. Tweakers zal niet verantwoordelijk willen zijn voor de content. Voor je het weet ben je meer bezig met modereren dan je core business. Krijg je mensen die gists gebruiken als pastebin voor allerlei content die elders op de site niet door de beugel kan. En dan krijg je alleen maar gezeur over wat je wel en niet laat staan.
Kan vergelijkbaar zijn met tweakblog; klopt maar eind raak, gaat t fout kan men ingrijpen.
Tweakblogs heeft voordelen in moderatie: er zijn weinig actieve gebruikers, het heeft een mainpage en de content is beperkt tot één pagina. In een GitLab repo kun je op heeeel veel manieren dingen verstoppen: in files, in merge requests, in duizenden files binnen een repo, tientallen versies van die files in branches, in issues... en dat is nog maar het topje van de ijsberg. Denk alleen al aan de ellende die je krijgt als mensen controversiële repos forken of clonen en heruploaden.
controversiële repos forken of clonen en heruploaden
Nu ben ik toch benieuwd? Welke hello world gaat te ver?
Volgens mij heb ik vrij duidelijk uitgelegd dat content in een repo niet beperkt hoeft te zijn tot code ;)
Volgens mij heb ik vrij duidelijk gevraagd om voorbeelden. ;)
Youtube-dl ?
Ik moest even googlen, maar je hebt het over dat google er niet zo blij mee is?
Software die gemaakt is voor expliciet alleen pirating van Copyrighted materiaal is hier nooit toegestaan. Zelfde als direct linking naar warez en andere downloads.

Als je die code dan upload naar een git beheerd door tweakers ….
Ik gebruik yt-dlp om youtube te streamen over tor naar mijn media player, dat is geen piraterij?

Je maakt hetzelfde standpunt als de reageerders op nu.nl dat tor alleen voor pedofielen is.
Ik gebruik yt-dlp om youtube te streamen over tor naar mijn media player, dat is geen piraterij?
Is het juridisch gezien wel. Jij hebt de rechten niet om die content op te slaan of af te spelen op een ander apparaat anders dan dusdanig aangeduid via de voorwaarden van het platform. Ik weet niet hoe je die spullen streamed naar je mediaspeler, maar als daar ook storage in die pipeline zit is het gewoon piraterij, want je hebt er geen geldige licentie voor. en voordat je begint over "thuiskopieregeling": ja dat mag, maar! het is verboden in Nederland om DRM omzeiling te doen YT-DLP geeft ook aan dat ze websites die voornamelijk DRM protected stuff serveren niet gaan ondersteunen als source. YT doet dat vooralsnog niet altijd, maar wel steeds vaker. vooral bij 4K spul.
Je maakt hetzelfde standpunt als de reageerders op nu.nl dat tor alleen voor pedofielen is.
wow waar komt dat nu ineens weer vandaan? Beetje overdreven nietwaar?

Youtube-dl(c/p) kan alleen maar gebruikt worden voor auteursrechtenschending en contractbreuk. Dat wil je als tweakers niet gaan hosten.

De reden dat de oorspronkelijke YT-DL niet meer online is, komt door het feit dat google heel prima aannemelijk kon maken dat het wel degelijk piraterij was, anders hadden de originele maintainers prima die rechtszaak gewonnen, maar daar hebben ze van afgezien.
Lijkt me geen piraterij, want opslaan doe ik ook in mijn cache als ik het via de site bekijk.
wow waar komt dat nu ineens weer vandaan? Beetje overdreven nietwaar?
Doelde meer dat als er keihard wordt gezegd dat youtube-download alleen voor piraterij is, is dat net zo'n reactie als op nu.nl dat mensen zeggen dat tor alleen voor pedo's is.
Youtube-dl(c/p) kan alleen maar gebruikt worden voor auteursrechtenschending en contractbreuk. Dat wil je als tweakers niet gaan hosten.
Contractbreuk nog wel, ik heb nooit wat getekent hoor.
De reden dat de oorspronkelijke YT-DL niet meer online is, komt door het feit dat google heel prima aannemelijk kon maken dat het wel degelijk piraterij was
nieuws: Bekende YouTube-downloader gaat offline na auteursrechtenclaim

Dat was niet door google en het is nooit tot een rechtzaak gekomen, dus we weten niet wat de wet er precies van vindt.
Ook weer zo, vanuit die kant nog niet bekeken.

Andere kant; er zijn al 1001 plekken waar je source kunt delen
Anoniem: 420148 @himlims_5 augustus 2022 13:37
Een git-repo is qua bestandsgrootte enkel duizenden malen groter dan een gratis blogje. Tweakers moet dan de opslag en bandbreedte gaan betalen voor een heleboel gebruikers.

En GitLab is best wel een zware jongen om te draaien, overigens. Ongeveer 8 cores en 8GB RAM per 1000 gebruikers.

[Reactie gewijzigd door Anoniem: 420148 op 28 juli 2024 21:22]

Voor wat het waard is: https://keybase.io/
En dan gaat het met name om deze feature: https://book.keybase.io/git

Je hebt alleen Git, that's it.
Dus geen mooie UI en handige functies die Gitlab en Github hebben.
Dat laatste ben ik het ook mee eens. Ik host nu mijn eigen gitlab maar dit zou ik de moeite waard vinden
Waarom Github niet aanraden ? Daar kan je toch ook je eigen projecten op plaatsen zonder kosten.
Een grote boze corporatie is daar eigenaar van....
'zonder kosten' bestaat trouwens niet, je betaald altijd prijs ook al is die niet even duidelijk.
Github copilot kan bijvoorbeeld jouw code even lenen voor andere projecten :+
Voor een bedrijf dat 253 miljoen dollar omzet had in 2022 [0] lijkt mij 1 miljoen besparen niet zo heel veel. Volgens mij is de PR/imago schade bijna even groot.

Er zijn veel open source libraries die “af” zijn en minder dan 1x per jaar een update krijgen. Waarschijnlijk de helft van alle ruby gems, of npm packages. Dat zijn libraries die waarschijnlijk door niet betalende users maintained worden.

Door deze actie zet Gitlab zichzelf buitenspel als serieuze source code hosting voor open source libraries. Nu zal iedereen wel terug naar Github gaan, of allesinds daar blijven.

Spijtige zaak

[0] https://www.macrotrends.n...harts/GTLB/gitlab/revenue

Update: Gitlab heeft na de backlash hun beslissing teruggedraaid. Ze gaan ongebruikte repo’s opslaan in goedkopere “object storage”.

https://twitter.com/gitlab/status/1555325376687226883

[Reactie gewijzigd door AndrewF op 28 juli 2024 21:22]

Er zijn veel open source libraries die “af” zijn en minder dan 1x per jaar een update krijgen. Waarschijnlijk de helft van alle ruby gems, of npm packages.
Toch is mijn ervaring met npm packages die "af" zijn en niet meer geüpdatet worden niet altijd even goed. Vaak zijn er bugs ingeslopen doordat de rest van de technologie wel doorontwikkeld. Packages die vaker geüpdatet worden genieten mijn voorkeur en heb ik minder problemen mee. Een jaar is misschien krap, maar als iets bijvoorbeeld 3 jaar niet geüpdatet is, dan is het nog maar de vraag of het waarde heeft.
In het npm ecosysteem gaat het best snel en lijkt er meer nood te zijn voor updates.

In ruby land zijn de zaken al een decenia of zo gestabiliseerd. Je kan op rubygems.org zoeken naar gems die geen update hebben gehad in het laatste jaar. Van de gems met meer dan 100K downloads, zijn er 3696 geupdate in het laatste jaar, en 8718 niet geupdate in het laatste jaar, waaronder rake, multi_json, rubyzip, pry en andere essentiële gems.

https://rubygems.org/sear...+updated%3A+%3E2021-08-01
https://rubygems.org/sear...+updated%3A+%3C2021-08-01
Voor een bedrijf dat 253 miljoen dollar omzet had in 2022 [0] lijkt mij 1 miljoen besparen niet zo heel veel.
Maar ze hebben al 150 miljoen dollar verloren dit jaar. Je wilt gewoon besparen waar je kunt besparen als je alleen maar verlies draait sinds je de markt op gegaan bent als bedrijf. Misschien zeggen ze dit wel om te zien wat de backlash is en dan de beslissing nemen.

That said, ik vind gitlab de beste van alle devops platforms, ze hebben veel integratie met allerlei andere producten (Kubernetes, prometheus), CI/CD is heel goed geregeld. Ik hoop dat ze winst gaan draaien en verder kunnen ontwikkelen.
voel als "we hebben meer funding nodig"... ANDERS...

rare manier om dit zo ter wereld te brengen...

verder ik moet hier altijd denken aan right to repair... straks weer een hoop dingen die niet meer werken
of niet meer te downloaden zijn. zoals bij google code.

weer een hoop hardware en software die wanneer de fabrikant geen support meer geeft en
door de community bruikbaar zijn gehouden (of verbeterd)... verdwijnen... en dan jarenlang in google search blijven rondhangen... net of elke developer nog leeft, zin heeft in, ... om het over te zetten op een ander platform.

the end gitlab... sorry about the extra e-waste...

[Reactie gewijzigd door trixwood op 28 juli 2024 21:22]

Mooie reden om alles (weer terug) naar GitHub te migreren.
Of om gewoon eens geld te gaan betalen voor de diensten die je gebruikt? Hallo? Gratis bestaat niet.
Zoals je zelf al zegt: "Gratis bestaat niet.". Met andere woorden, mijn afname werd blijkbaar al betaald, dus waarom zou ik die kosten nu ineens moeten ophoesten? Maar goed, ook als we dat buiten beschouwing laten vind ik de volgende, $19 per maand tier, wel echt heel erg duur. Ik gebruik GitLab met name voor het hosten van wat oudere open-source projecten. Uiteraard zou ik dit ook gewoon lokaal neer kunnen zetten (ook gratis!), maar dan kan ik deze projecten niet eenvoudig delen.

Aanbieders moeten eens stoppen met te denken dat ze dienstverlening X voor noppes kunnen aanbieden om daar daarna maar op terug te komen met aanvullende voorwaarden. Deze drugsdealer methode klinkt leuk om gebruikers te trekken, maar voor mij werkt die niet. Vooral omdat er voor GitLab directe gratis of goedkopere alternatieven zijn. Met name voor hobbyisten.
Misschien komen die projecten in aanmerking voor het GitLab for Open Source Program.
Dan krijg je GitLab Ultimate en het lijkt mij dat daar de maatregel van het archiveren niet van toepassing is.
Of wij moeten eens stoppen met verwachten dat alles maar gratis is?
En hobby's kosten nou eenmaal geld.
Waarom zou ik in godsnaam aan GitLab $19 per maand betalen als er een gratis, beter alternatief is? Ook is de meeste dienstverlening niet kosteloos. Alleen betaal je er op andere wijze voor. Bijvoorbeeld met jouw persoonlijke data.

Als ik het dan toch zelf host is het ook weer niet gratis. Immers moet ik de versiebeheersoftware op enige manier onderbrengen. Mijn hobby kost dus al geld. Maar het is naïef om te gaan betalen voor iets wat je ook zonder girale middelen kunt verkrijgen. Immers kan ik mijn euro ook maar één keer uitgeven.
Ik reageerde alleen op het hobby gedeelte, hobbies zijn duur.
En waar betaal je mee als je op github zit, daar maak ik mij meer druk om.
Crawlen doen ze toch wel (ze zeggen het hier letterlijk), waarom dan extra betalen?
In het geval van GitLab heeft 'gratis' voor de kleine gebruikers wel bestaansrecht volgens mij: GitLab wordt betaald door zakelijke klanten. Mensen die voor hun hobbyprojectjes en om te experimenteren gratis gebruik willen maken van GitLab kunnen dat, en kunnen die ervaring weer meenemen naar hun werk. Of omgekeerd, zijn er al bekend mee vanuit werk en gaan het thuis ook gebruiken in plaats van thuis de concurrent te proberen.

Het bedrijfsleven betaalt indirect voor de hobbyist en voor het opensourceproject. En dit model levert GitLab een grotere userbase en meer data over gebruik van het platform op, wat GitLab weer kan gebruiken voor het verbeteren en verkopen van het platform voor betalende klanten.

Wat mij betreft een prima model.

[Reactie gewijzigd door ChillinR op 28 juli 2024 21:22]

Of andere, FOSS, hosting platformen zoals Codeberg of Sourcehut.
Terug naar SourceForge
Ik voel al bots aankomen die elk jaar een opmerking gaan plaatsen op repositories. Ik weet niet of GitLab hier veel mee opschiet.
Bor Coördinator Frontpage Admins / FP Powermod @stijnb12344 augustus 2022 18:38
Denk je? Wat schiet je daar netto gezien mee op? Als je al geen enkele comment plaatst, commit doorvoert of issue meldt; hoe actief ben je dan en wat heb je dan aan het account dat je zo ver wilt gaan om bots te gebruiken om het account te behouden?
Behoud van de sourcecode. Je weet maar nooit of over 10 jaar iemand iets van wilt gebruiken. Dit zie ik vaak terug bij oude projecten van handhelds (voordat GitHub/GitLab veelal gebruikt werd), was de sourcecode als bijlage geüpload of op een website die al uit de lucht is of Google Code archive bijv. Voorbeeldje hiervan zijn projecten van de PSP. Gelukkig is er aardig wat op GitHub, maar veel is met de tijd verloren op oude fora.
Als die sourcecode zo belangrijk is, is het ook niet erg om een beetje te betalen voor opslag of zelf iets in te regelen om het te bewaren.
Ik heb veel persoonlijke projecten op gitlab staan. Dingen waar ik jaren geleden mee heb geklooid. Een robotica project, tooltjes, bash scripts, etc. Ik zoek met enige regelmaat nog wel eens iets op in een oude repo. Hoe deed ik dat toen ook alweer? Of soms is de code goed zoals ie is, en hoef ik er jaren niets aan te doen. Ik zou nog best een paar euro per jaar willen betalen zodat dit bewaard blijft, maar $228 per jaar vind ik daarvoor wel érg veel. Ik zal mijn code waarschijnlijk dus weer (terug) verhuizen naar github.
Gitlab-ce op een lokale server installeren. Dan heb je alles zelf onder controle.
Ik zou eerder zeggen, zet een opslag limiet van 5 GB op een gratis account. Een beetje zoals de gemiddelde cloud drive. Stel je voor dat Google/Microsoft/Dropbox je bestanden op je kleine gratis cloud drive gaat verwijderen na 2 jaar. (vraag mezelf nog steeds af waarom Dropbox zo populair is/was, want 2 GB is toch echt heel weinig vergeleken met wat GDrive en OneDrive gaven (15 GB, OD nu nog maar 5 GB)).
Bij Dropbox kon je extra GB's bij 'sparen.'
Ja, maar dat was dan gelimiteerd tot +5 accounts waarbij je 500 MB extra kreeg (dus totaal 2.5 GB) dat is niet echt concurrerend vind ik. Verder weet ik niet hoe je meer kreeg. Ik denk dat het nogal gepromoot werd omdat het met OEM computers kwam (met tig veel bloatware).
Een beetje niet. Maar een beetje bestaat niet bij Gitlab.
Bor Coördinator Frontpage Admins / FP Powermod @FPSUsername4 augustus 2022 18:56
Behoud van de sourcecode
Een goed argument maar daar bieden ze dus eerder genoemde opties voor. Die mogelijkheid is er dus gewoon. Optimaal is het niet, dat ben ik met je eens.

[Reactie gewijzigd door Bor op 28 juli 2024 21:22]

Bij GitHub kun je je source code archiveren. Ik denk dat dat een mooiere oplossing is. Project is afgerond en zal er voor "altijd" blijven staan (werkelijk waar geen idee, maar wie weet 30 jaar zoals logdata in de medische wereld?).
Maar als dat kan, waarom zou je dan inactieve projecten verwijderen en niet gewoon automatisch archiveren?

Ik wist bijv. niet. Ik log 1x in de zoveel tijd in om wat source als demo/test zaken op GitHub te gooien voor het geval anderen een voorbeeld zoeken zonder het wiel opnieuw uit te moeten vinden. Oude code heb ik af en toe weer eens nodig en update ik, maar sommige dingen ook gewoon niet. Dat zou dan dus verdwijnen.
[...]
Een goed argument maar daar bieden ze dus eerder genoemde opties voor.
Welke dan? Die staan niet in het artikel.
Wat is nu je punt? Want het gaat de ontwikkelaar dus niet perse om actief zijn door inhoudelijk te onderhouden en ook niet perse om een bedrag betalen wat het bedrijf graag vraagt. Dus een bot inzetten om op dezelfde plek de code te behouden/blijven archiveren is hoe dan ook al een optie.

Het argument van een bot inzetten toont dat wat een klant nodig heeft niet hetzelfde hoeft te zijn als wat het bedrijf graag wil. Het bedrijf wil besparen door de mogelijkheden voor klanten van de gratis diensten te beperken, door het of te onaantrekkelijk te maken of er extra aan te verdienen. De klant wil de besparing die ze voor zichzelf hadden zo veel mogelijk behouden, meer betalen of (al dan niet onbewust) geen zaken meer doen. Met de optie van de bot is eerder de vraag wat het bedrijf er nu mee op gaat schieten. Ze speelde eerst in op een gratis dienst zoals een archief, en komen straks mogelijk niet uit op de besparing en een slechtere reputatie diensten stop te zetten. Met de vraag waarom. Het heeft er veel van weg dat ze diensten gratis aanbieden die ze niet kunnen volhouden of zomaar niet willen volhouden zonder met klanten te overleggen.
klopt, laatst nog bezig geweest aan een project van 2002. Die code stond letterlijk nog op een zip-drive (en ja, dat ding nog aan de praat gekregen ook)

Dichter bij huis bleek ik code,die ooit voor een vorige werkgever geschreven was, nodig te hebben in een nieuw project. dan ben je erg blij dat dat na 6 jaar nog onaangeroerd op github staat. (nee vorige werkgever gaat niet miepen, want we werken nog steeds samen...)
Ik loop vaak zat tegen projecten aan op github (to be fair zelden op gitlab) die al jaren inactief zijn maar mij toch enorm hebben geholpen. Dat betekend niet persee dat ik opeens een depency maak op een antieke repo, maar wel de code in kijk en daar van leer en zie hoe iemand iets specifieks geflikt heeft.

Voorbeeld die mij toevallig vers in het geheugen staat; weakrefs in go, project is al jaren dood, maar ik heb veel aan de source code gehad om iets vergelijkbaars te maken.

Inactief != dood
Heb je geen betere referentie? Vind deze toch een beetje weak.

:+
gewoon een makkelijke overal bereikbare plek voor je code die (publiekelijk) gedeeld mag worden.
https://qz.com/646467/how...ing-a-tiny-piece-of-code/

Omdat anders dit soort dingen gemeengoed kunnen gaan worden?
Simpele code die gewoon doet wat het moet doen, een dev die misschien dood is, of zijn login's kwijt is en een tijdelijke e-mail gebruikt had.
Open source libraries die “af” zijn.

Er zijn voldoende voorbeelden van OSS libs die al een jaar geen update gekregen hebben (bvb wkhtmltopdf, waarschijnlijk de helft van alle rubygems, npm packages, enz).

Als het klopt dat deze repo’s voor 25% van de hosting kosten zorgen, dan betekend dit waarschijnlijk dat ze wel regelmatig gedownload worden. Als ze namelijk niet gedownload/gelezen worden, dan kosten die enkel en alleen disk space, en dat zou toch niet de voornaamste hosting kost mogen zijn. Zeker niet voor weinig gebruikte repo’s die op tragere disks kunnen staan.
Heb je enig idee hoeveel git repositories er bestaan op bijvoorbeeld GitHub die gearchiveerd zijn? Iedere repo die equivalent daaraan is op GitLab zou dus gewoon verwijderd worden. Wat met repo's die gewoon voorbeeld code bevatten voor andere mensen om op voort te bouwen en nooit aangepast moeten worden?

Dit is ronduit absurd.

Verwachten dat iedereen dan maar om het jaar een comment gaat plaatsen gewoon om een project te kunnen behouden is absurd.
Die paar procent van de mensen die dit gaan doen hebben ze misschien al meegenomen.
Meerendeel is vergeten dat er code staat, of is het bijvoorbeeld een onnodige fork oid die ze niet meer gebruiken.

Als je je project actief wil houden voor bijvoorbeeld oude portfolio code oid, dan kan je inderdaad denken aan zo'n bot. Maar ik denk dat dat percentage heel klein is tegenover alle inactieve projecten van mensen die echt niets meer mee doen. Hun zal het ook niet uitmaken dat die code niet meer beschikbaar is denk ik.
Geen idee hoe Gitlab werkt maar bij Github zou het een probleem kunnen worden als voor onafhankelijke projecten een url naar een source bestand wegvalt omdat ze er gewoon vanuit gaan dat het bestaat. Een stap verder is dat het beleid gebruikt wordt om projecten te dwarsbomen als er iets niet aan bevalt.

[Reactie gewijzigd door blorf op 28 juli 2024 21:22]

"Een stap verder is dat het beleid gebruikt wordt om projecten te dwarsbomen als er iets niet aan bevalt."
Dat is wel énorm ver gezocht in deze context.
Het is een product waar zij ook regels voor hebben, als hun iets niet bevalt kunnen ze dat toch al.
Dit voegt daar niets aan bij imo.
Als je echt bang bent, moet je niet afhankelijk zijn van zulke partijen, en alles zelf gaan hosten.
Uiteraard ben je dan nog steeds afhankelijk van providers, en kunnen providers etc jou nog steeds dwarsbomen. Maarja :shrug:
Je hebt in principe gelijk. Het enige dat zelf hosten op je eigen server in je lokale netwerk als voordeel heeft fat je het dan nog steeds kan delen met iedereen die je toegang tot je netwerk hebt gegeven.

Toegegeven, qua delen van code (zeer) ver van ideaal, maar zolang je stroom hebt, is je eigen netwerk nog wel in de lucht en heb je nog altijd de beschikking over je code en kan je nog steeds 'pullen' en 'pushen', zoals je gewend bent.

Een VPS/Gitlab CE combinatie lijkt mij dan de meest ideale vorm van code hosten en delen met anderen, zonder je een boel ge-emmer van je ISP op je dak te krijgen omdat je een eigen server in je lokale netwerk beschikbaar wil stellen aan het internet.

Dus maar een zakelijk account afgesloten met de ISP hier ruim 10 jaar terug. Want ik heb een eigen IP bij diezelfde ISP voor mail, website en DNS die ik lokaal host. Maar deze ISP verrekt het om reverse DNS aan hun kant goed in te stellen, want ze beheren onze DNS server niet. De DNS server van de ISP onderschept echter wel Reverse DNS traffic. Onze DNS server is wel goed ingesteld, maar ja, Reverse DNS traffic komt niet aan. Andere ISPs zijn nu ook beschikbaar, maar die hebben dan weer geen optie om daar een eigen IP adres aan te vragen.

Waarom met al dit gezeur blijven zitten? Internet en electriciteit is hier in Paraguay behoorlijk instabiel. De baas heeft daarom besloten om alles in eigen beheer te hebben en te houden. Zonnepanelen komen binnen een paar maanden naar deze locatie en dan worden hier zo'n beetje het hele dak volgelegd. Kan de generator eindelijk de eeuwige jachtvelden in en is er alleen nog instabiel internet als probleem over.

Een boel woorden, maar het zal hopelijk wel duidelijk zijn geworden dat ik heel goed snap wat een probleem het is als je afhankelijk bent. Als alles lokaal draait, staan de werknemers hier in elk geval niet stil. Zelfs al kregen we er geld bij, dan nog is de cloud geen optie vanwege instabiliteit. Ge-emmer waar je in Nederland praktisch geen last hebt als je het vergelijkt met hier.
Internet raakt vol met dode mensen en profielen. Het is echt niet zo dat iets op internet eeuwig blijft bestaan.
Bij deze specifiek use case gaat dat niet op. sommige code is statisch en wordt veelvuldig gebruikt door andere projecten. Ben dus benieuwd naar de definitie van inactiviteit
Code waar nooit meer een letter in gewijzigd wordt is echt ontzettend zeldzaam. Er zullen altijd kleine aanpassingen gedaan worden gedurende de life cycle.
Mij lijkt code die niet meer, of lange tijd niet, bijgewerkt wordt net ontzettend gangbaar. Wij gebruiken bijvoorbeeld vaak github om aan onze LaTeX code van papers te werken. Afhankelijk van de journal ben je al snel een jaar verder tussen het indienen van een tekst en het ontvangen van de reviews. Het is nogal een tegenvaller als uw bron dan weg is omdat uw repository een jaar onaangeroerd is gebleven. Ook jaren na een accept is het vaak handig om toegang te hebben tot de broncode van de publicatie, bijvoorbeeld omdat je een afbeelding wilt herbruiken. Uiteraard zou je dat kunnen oplossen door een betaald account te nemen, maar in veel andere landen hebben bijvoorbeeld doctoraatsstudenten die luxe niet (slecht loon en universiteit dekt veel onkosten niet. Niet over te klagen in België trouwens.).

Bij papers hoort ook vaak een referentieimplementatie die gebruikt kan worden door derden om de resultaten na te bootsen (veel voorkomend nu met machine learning). Die dingen worden bij publicatie ook vaak online gezet met een gratis account en daarna niet meer aangeraakt. Dat zou dus ook verdwijnen na een jaar (ervan uitgaande dat deze regel ook voor open-source projecten geldt).

Daarnaast ben ik al vaak genoeg nuttige implementaties, documentatie of libraries tegengekomen die in geen jaren meer aangeraakt zijn, maar nog veel gebruikt worden.
Helemaal mee eens. De actie van GitLab is ergens begrijpelijk, maar ik ben benieuwd of dit het gewenste resultaat gaat opleveren voor ze.
Volgens het Register artikel gaat het dus inderdaad puur om wijzigingen gerelateerd aan de repo (commits, issues, comments, enz) en dus niet het gebruik (clone, fetch) daarvan. Een statische repo zou dan dus gewoon verwijderd worden.

Soms is het niet heel gek als er een jaar lang geen updates in een repo gedaan worden, dus dit kan nog wel eens lastig worden.
Hopelijk kan archive.org hier iets mee. We kunnen nu vaak niet zeggen hoe waardevol iets (geweest) is.
Als de code van een overledene verdwijnt nadat deze persoon is geregistreerd als overleden, dan raakt de opmerking in je post wel de spreekwoordelijke 'kant en wal'. Maar als een persoon overlijdt, dan betekend dat alleen dat er geen nieuwe updates meer van deze persoon kunnen worden verwacht.

Maar de code blijft gewoon bestaan. Qua kosten voor opslag en backups maakt het amper uit voor de beheerder of die code er wel of niet staat. Code is uiteindelijk tekst en dat neemt van zichzelf relatief weinig opslagruimte in beslag en kan flink worden gecomprimeerd, als dat nodig is. De kosten zitten hem in het serveren van de code. Dat blijft geld kosten, want daar is veel mer energie voor nodig (dan voor opslag en backup). Energie word niet goedkoper.

Daar is waar Gitlab, in dit geval, over valt. Kosten van het hosten, niet voor opslag/backup. Verhuizen naar 'trage' servers welke zijn ingesteld voor laag verbruik, daar kan de code van de overledene gewoon blijven bestaan en in mindere mate gewoon beschikbaar blijven voor iedereen op het internet.
Geld dat ook voor prive repos, ik heb een aantal repos op Gitlab waar ik heel af en toe wat aan wijzig, zou het niet leuk vinden als ze mijn repos ineens zouden verwijderen. Nu wil ik gaan kijken hoeveel zo'n subscriptie nu kost en krijg ik de volgende melding.
Subscription service outage
The GitLab subscription service (customers.gitlab.com) is currently experiencing an outage. You can monitor the status and get updates at status.gitlab.com.

[Reactie gewijzigd door Hydranet op 28 juli 2024 21:22]

Precies mijn gedachte. En de prijs van 20 dollar per maand vind ik dan vrij fors voor enkel het online houden van de repos. Dan zou ik eerder een lite variant verwachten waarbij je niet alle features krijgt, maar bijv. wel X GB aan opslag.
Als het echt klopt dat het $19 per maand is wat per jaar word afgeschreven en dus in totaal $228 is.
https://about.gitlab.com/pricing
Zo te zie klopt dat dus wel. Ik gebruik zoveel mogelijk opensource producten maar op deze manier is Github free of Pro($4 per maand) wel wat aantrekkelijker qua prijs.
Kun je beter Codeberg (hosted Gitea instance) of Sourcehut overwegen.
Codeberg ziet er erg interessant uit, bedankt!
Aan de terms of use te zien is het alleen bedoeld voor opensource projecten, dat zijn mijn prive repos niet.
Private repositories are only allowed for things required for FLOSS projects, like storing secrets, team-internal discussions or hiding projects from the public until they're ready for usage and/or contribution. They are also allowed for really small & personal stuff like your journal, config files, ideas or notes, but explicitly not as a personal cloud or media storage.
Ik heb intussen mijn eigen gitea draaien :)
Kijk, ook een goede optie. Veel plezier ermee!
Als je zelf al wat dingen host kan je Gitlab ook zelf hosten.zie

Je hebt dan aardig wat mogelijkheden alleen vergt het wel onderhoud en tijd.
Gitlab zelf hosten is een beetje overkill voor mijn paar kleine prive repos, gitea klinkt wel interessant.
Je zou ook kunnen overwegen om gitea zelf te hosten. Als je alleen wat privé-repos hebt draait dat waarschijnlijk prima op de goedkoopste variant van bijvoorbeeld Digitalocean, Linode of Hetzner.
Ik heb nu mijn eigen Gitea draaien op mijn vps, bedankt voor die tip! Fijn dat die wat simpeler is want al die extra functies van Gitlab ga ik nooit gebruiken.
Zou een beter oplossing niet zijn om gewoon om elk (half)jaar een link in de mail te sturen waar je op moet klikken?

Dan moeten mensen daadwerkelijk een teken van leven geven.
Anders zie ik al voor me dat je een bot kan downloaden welke op Gitlab wordt gehost die elke maand even een issue plaatst en deze gelijk weer sluit.
Want bot kan geen link in een mail openen? Het is gewoon om de overgrote meerderheid aan dode projecten weg te gooien. Je kan ke wel afvragen als een jaar niet te kort is.

[Reactie gewijzigd door xzaz op 28 juli 2024 21:22]

Dat kan een bot zeker. Maar mijn bot kan niet op jouw mail maar kan wel een teken van activiteit plaatsen op jouw git
Het feit repo uitontwikkeld is betekend niet dat hij geen nut meer heeft... Maar het is gratis en er zijn veel gratis alternatieve en daarbij wordt de brei van data als maar groter en wordt er weinig weggegooid. Dit zou misschien kunnen helpen het internet een klein eentje op te schonen.
En repos welke elders gebruikt/geimporteerd worden, maar waar geen wijzigingen (of minder dan eens per jaar) meer worden toegepast ? Daar zijn er flink wat van.

Op dit item kan niet meer gereageerd worden.