I prefer to do my project management in in disjunct tools from the actual source control (and I dislike the tech stack of most integrated solutions), so my main repository host is running fugit[1], which simply allows push/pull access on a per-ssh-key basis. Some repositories are then exposed to the Web using cgit[2]
As others have already stated, this article is a great introduction for when you'll be the only one to access the repositories, as anyone able to authenticate for that account will have access to all repos.
There are some tools that restrict access with varying levels of granularity, but if you just want to restrict access on a per-repo-per-sshkey basis, one of my projects is a simple shell script that does just that:
It originally came to be because I've found gitolite too big to maintain for simply sharing some repositories with a few other people. It has since served me well and is used in some business applications, too.
I'd really like to use this if it were just a simple command line tool as advertised. As it is, I can't really figure out what part of the source distribution to run.
The whimsical naming of files and tools IMO drives potential users away more than it helps in engaging people. Mostly it just makes it hard to find out how to use something.
The fact that zookeeper also is the name of another (completely unrelated) software project does not really help, either.
Other than these points, thanks for caring about making the web accessible! All too many websites completely disregard that aspect and ignore users for which these things are deal breakers.
Not to plug my own projects unduly, but I've grown tired of writing configuration files running to hundreds and thousands of lines and kind of snapped and implemented the basic protocols (SMTP & POP3) myself - the project is @ http://cmail.rocks/ (and https://github.com/cmail-mta/cmail).
I've since moved all my mail for the last year (for about 10 domains) via a cmail setup and so far have not had a major hickup. Sure, it may not be as full-featured as other mail servers, but thats not the mission statement ;) One of the main reasons I'll probably never go back (besides pride) is the ease of altering the runtime configuration via our admin tools (eg. adding a new domain to the mail server is one command in the simplest form).
Some of my peers who contributed code or bug reports also run instances and are very happy with the amount of configuration they need to support for cmail vs. the amount of things to do to run for example exim.
Code-wise, it's still C (because that's what I'm most comfortable with), but hopefully it doesn't read as ancient :) I've tried to keep the bulk of it understandable and modular. We extensively use static analysis (clang analyzer and Coverity Scan) as well as fuzzing with afl-fuzz as part of our testing.
IMAP is the only major protocol we do not yet support (though the groundwork is laid in another branch of the main repo), and that's mainly because the specification is a major PITA (at least compared with the relatively sanely specified SMTP and POP3). IMAP also implicitly requires multithreaded handling of connections, which so far cmail has managed to avoid, because in my experience multithreading is a) not necessary in most sane server designs and b) a major source of non-trivial bugs.
Edit: Oh, since you mention build systems - we use a simple makefile, so yeah, no m4 macros ;)
Kind of off-topic, but since I see it (mis-)used here, I kind of dislike how the term 'router' has become synonymous with 'SOHO Wifi Access Point / Modem / Router thingy'...
In most 'professional' settings, all of these things are actually completely different devices with clear purposes, and this script would actually do nothing against a router. It might freak out some APs, but that's about it.
Yes, this will only affect the AP and not the router. The devices that I tested it against were consumer home routers that also serve as APs. My title might be better as 'DoS any home Wifi network with 7 lines of Python and 1 library'.
I've been using TC for multiple projects involving Thin Client hardware provisioned in remote locations (such as remote security cameras at a festival and POS nodes/signage displays/twitter walls at conferences) and it really is a great project.
Being able to run a complete distribution off a cheap 128MB CF card is a great thing, especially because the packaging process for TC is really simple - packages are simply squashfs files being mounted to / after booting.
Customization and deployment (editing some files and dd'ing the image to the disks) is also really simple. The package repository is a bit clunky and not as big as you'd get with a major distro, but that should not really be a deterrent (see above).
I've never had those problems with my laptops (though I exclusively use Thinkpads). Multi-monitor works pretty well out-of-the-box with the big desktop managers (Gnome/KDE), and even using xrandr manually is not that hard.
Audio with alsa has also been a painless experience for me, though I heard differently from some people.
Using Debian (which is not well known for always having the most up-to-date releases), I've as of yet never had to compile my own kernel to enable any of these.
[1] https://github.com/cbdevnet/fugit [2] https://git.zx2c4.com/cgit/