Similar projects and alternatives to operations-mediawiki-config
Wikimedia Foundation operates some of the largest collaborative projects in the world. This is the Puppet repo for our servers. This repository is a mirror; see https://www.mediawiki.org/wiki/Developer_access for contributing.
🌻 The collaborative editing software that runs Wikipedia. Mirror from https://gerrit.wikimedia.org/g/mediawiki/core. See https://mediawiki.org/wiki/Developer_access for contributing.
Appwrite - The Open Source Firebase alternative introduces iOS support. Appwrite is an open source backend server that helps you build native iOS applications much faster with realtime APIs for authentication, databases, files storage, cloud functions and much more!
Your self-hosted, globally interconnected microblogging community
Multi-Cloud :cloud: Object Storage
MediaWiki used on Arch Linux websites
Clean code begins in your IDE with SonarLint. Up your coding game and discover issues early. SonarLint is a free plugin that helps you find & fix bugs and security issues from the moment you start writing code. Install from your favorite IDE marketplace today.
operations-mediawiki-config reviews and mentions
The falsehoods of anti-AGPL propaganda (2020)
3 projects | news.ycombinator.com | 24 Oct 2021
> Configuration is just a short artifact. It's not a creative work and is therefore not copyrightable at all, whether by AGPL or otherwise.
I'm doubtful. For example https://github.com/wikimedia/operations-mediawiki-config is wikipedia's config. It is not short, and much of it is complex enough i think it would be copyrightable (ianal)
I agree though a very traditional list of key value pairs that are simple facts like where to find the db, might lack creativity to be copyrighted (ianal). But how many real deployed systems have that simple a config. More generally i would prefer that the license was less ambigious about this especially in an international context (e.g. rules are totally different in uk over what can be copyrighted)
> I'm not convinced obscurity helps against spam at all. DKIM and blocklists have done much more against email spam than any form of "security by obscurity" corporate scheme has.
Gmail et al use techniques beyond dkim that are secret. However i meant more like web spam where you can't just rely on source vouching for users. For example on wikipedia there is a feature where admins can write "code" that block patterns in edits. When used against persistent vandals, they are often secret lest they use the info to adjust behaviour. That's the type of thing i mean.
> if you are coordinating with the developers, then you have their explicit permission to temporarily withhold those changes (AGPL copyright holders can still grant exceptions to the license)
That only works if one entity holds all the copyright. Even then, does that mean forks cannot have coordinated disclosure?