Actually I think active is probably the wrong word, so changed in the post, but to answer your question:
It's a system based on multiple web services and run across multiple hosts, and I've included all system checks in that number. So we have checks for:
* ping, ssh, disk, load, network io, etc.
* error rates from request logs
* request rates (warning on high values)
* smoke tests for key functionality (i.e. does the search engine return results, can you complete certain forms, etc.)
* connection tests from relevant hosts to relevant services or databases
I'll give it a good few weeks, say a month, and then get the results together. It depends on how popular it is, if I'm still seeing results come in and how much time I can grab.
Thanks. I'd kept off all identifying information as some folks prefer to keep operational information secret. I'm hoping the complete anonymity gets me more filled out questionnaires.
I'll give it a good few weeks, say a month, and then get the results together. I'll post them to my blog (http://morethanseven.net) and I'll post the link on here too.
RVM is great. But by design it's a solution to compiling software on every machine. This simply doesn't work for lots of sysadmins, especially with lots of machines - it means installing a complete build environment which opens up much more evil.
Well, yes. And that's the effective situation we've got at the moment.
What I'm proposing is a full acknowledgement of that: if you want to live on the bleeding edge, then that should be supported as well as possible, but a very clear delineation should be drawn between the responsibilities of the distribution and those of the developer/sysadmin. RVM does that very cleanly, even if you only use it with the system ruby.
It's also guilty of being unattractive to the developers I'd love to see use it. The site says "Recent News: Dec 26th, 2009" and then concentrates on a NOTE TO SLACKWARE 8.0 USERS.
Showing the hello world of checkinstall would be much better imho, and it's what developers from the web world expect.
Checkinstall of Python and VirtualEnv is the only sane way I've found to do python development and deployment when you're developing on Maverick and deploying to Lenny.
That wasn't my aim. In fact I'm not using Debian at the moment as I indicated, I just know the commands better to give examples. This isn't about a specific distro, it's about the huge benefits of system packages and their toolchains in general. I'm not even really concerned with official packages and the official blessed package repos.
I've created hundreds of packages for OpenBSD and you just seem pretty gullible about the whole process.
You can't just write about the packaging process and hope people come forward to volunteer to do the actual work. There's a large amount of thankless sweat equity when you provide packages. People whine when things are broken and rarely send praise when it just works as it should.
If you really want to change the world, start with creating a Ruby apt repository for Debian/Ubuntu/whatever you use that people can actually deploy in production.
To my knowledge no. I think this is one of the main problems in getting people to create system packages. I think this fosters the split between package maintainers and developers. It's not that the documentation is all bad, it's just not aimed at the audience I think it should be.
System packages just aren't what web savvy developers grew up on and the documentation feels out of step. But the capabilities and tools around system packages are awesome.
I might take a go a writing a simple guide, but I'd be more than happy to see other people have a go that know more than I do. Let me know if this sounds of interest.
In lots of cases the separate package maintainer's do a good but ultimately thankless task. The example I gave between the rabbitmq packages which are built as part of the development effort and made available on the rabbitmq site and the solr packages which are sometimes out of date and not referenced by the site highlights the point I'm trying to make.
It's a system based on multiple web services and run across multiple hosts, and I've included all system checks in that number. So we have checks for:
* ping, ssh, disk, load, network io, etc. * error rates from request logs * request rates (warning on high values) * smoke tests for key functionality (i.e. does the search engine return results, can you complete certain forms, etc.) * connection tests from relevant hosts to relevant services or databases