liraz

Not true. If you cut down the number of preforked processes and use spamd spamassassin works just fine in a VPS with limited memory.

Also, SA leverages blacklist services (and other techniques, it's very configurable) and is easier to integrate into your mail server.

Proprietary vs free software isn't just about money. It's about freedom, control and security.

I've often found myself needing to patch the software I use to get it to work just right. Even when a proprietary software vendor gives you source code the build system often sucks and the code is not hacker friendly.

Also the licensing would restrict you from doing all sorts of things you wouldn't have to think twice about with an open source web server (e.g., auto-scaling in a cloud configuration)

Unless you need the backwards compatibility with Apache don't use LiteSpeed. There are excellent open source alternatives which are just as good and perhaps superior. Minus the Apache compatibility.

+1 for lighttpd. nginx is nice too but its configuration system is much more primitive by comparison.

For now everything is free but at some point we'll probably be adding premium services in an open source friendly freemium model that ensures we have the resources to sustain TurnKey and keep the project healthy.

The service is still in private beta but anyone can launch a demo session and get a good feel for the UX. Also, 100 of the first invitation requests from HN will be granted as soon we get them. At this point only a subset of the planned functionality has been implemented but the minimal viable product is there I think. We've been working on this for a few months now. Mostly we're looking for high-quality feedback and we expect our best shot at that is the HN community, which has been a major source for insight and inspiration for us during development. Thanks in advance for taking a look. Hope you find this useful!

According to John Sullivan, the operations manager for the FSF: "Those terms have previously even been unavailable for examination online. We are publishing them on fsf.org today in order to comment on their unethical restrictions."

Analysis of the H.264 patent licensing restrictions in the context of the Apple/Adobe back and forth on Flash and "open standards":

http://arstechnica.com/apple/news/2010/04/pot-meet-kettle-a-...

The meaty part is that they require all licensed software to include the following notice:

THIS PRODUCT IS LICENSED UNDER THE AVC PATENT PORTFOLIO LICENSE FOR THE PERSONAL AND NON-COMMERCIAL USE OF A CONSUMER TO (I) ENCODE VIDEO IN COMPLIANCE WITH THE AVC STANDARD ("AVC VIDEO") AND/OR (II) DECODE AVC VIDEO THAT WAS ENCODED BY A CONSUMER ENGAGED IN A PERSONAL AND NON-COMMERCIAL ACTIVITY AND/OR WAS OBTAINED FROM A VIDEO PROVIDER LICENSED TO PROVIDE AVC VIDEO. NO LICENSE IS GRANTED OR SHALL BE IMPLIED FOR ANY OTHER USE. ADDITIONAL INFORMATION MAY BE OBTAINED FROM MPEG LA, L.L.C. SEE HTTP://WWW.MPEGLA.COM

So even a $12,000 video camera needs to include a limitation on non-commercial "consumer" use. But would it be legal to try and enforce that?

Thanks, that's a good point. I actually stopped noticing that bit of silliness. I just sent Alon, who did an otherwise commendable job slapping together those icons in the GIMP, an email asking about that...

"Premature optimization is the root of all evil". We used SimpleCDN for a while, but the increase in performance didn't justify the increase in complexity.

I haven't run into any problems (yet) obstructing signal propagation in my scripts but as you point out it's not The Correct Thing To Do. For the sake of correctness I'll be updating my error handling code. I find doing the correct thing often saves me from debugging strange edge cases.

(replied to on blog comments as well)

I find using specific shebangs is a good habit if you don't know exactly which generic POSIX shell features/syntax you can rely on. In years past I would all too often use #!/bin/sh for the shebang only to find out later I had accidentally used a BASH specific shell feature, which is fine if /bin/sh happens to point to /bin/bash but can break if it points to something else.

OTOH, I believe the error handling tricks discussed should work with any POSIX shell so I've updated the shebang line in the code snippets to use the more generic #!/bin/sh.