SA is easy to integrate in a mail server but not "easier" than adding one line to the server configuration. SA lets many spam go through, it's a pain in the neck to fine-tune it and when you have a lot of spam coming in it uses a lot of CPU for parsing. With blacklist servers spam is dropped at the beginning, there's no further parsing etc.
Basically I don't know why anyone nowadays would use spamassassin (I've used it in the past) when there's graylisting and blacklist servers that work wonderfully with low overhead.
If time is money and you want easy configuration, spend the $200 on a VPS license for Litespeed. Since it can use the existing .htaccess and httpd.conf from apache, it really does take only 5 minutes to "upgrade" in most situations (and their support is 2nd to none).
But litespeed can get expensive for large installs so I don't blame people looking for free/opensource alternatives. All depends how much time you have and if you are building from scratch vs. upgrading an existing Apache install.
The great thing is, we have so MANY choices today compared to just 5-6 years ago, it's awesome.
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.
True, if more hardware is cheaper it's always a better upgrade.
But litespeed will certainly double the capacity of any Apache install, no exaggeration, and it's ddos resistance is second to none. I just wish it wasn't so expensive.
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":
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?
Don't you think there is a different license for commercial encoders? That commercial license probably comes with a stunning set of fees outlined in byzantine detail, hence the need to keep businesses from using the consumer license.
(I think the professional camera crowd doesn't do interframe compression in the camera anyway. It makes editing a little funny and they like very high quality source material. Google shopping for "video camera h.264" over $1000 only brought me a bunch of security camera packages.
The Canon Vixia HF S21 is over $1000 and contains the prohibition (well, the MPEG-2 version of it), sadly I can not paste it here because Canon set the no-copy bit on the downloadable PDF manual! Yes! That will defend the company from the evil threat of… umm… I can create no scenario where copying from the users' manual is a threat.)
I agree that the whole "non-professional" thing seems blown out of proportion. After you've shot and edited your masterpiece, run it though a "professional" encoder and you're done.
I work part-time for a production company and as far as I know, the industry standard is the RED Camera http://en.wikipedia.org/wiki/RED_Digital_Cinema, whose standard output is 2K-4K RAW.
Compressed formats that interpolate between keyframes (like MPEG) are generally a bad idea since they make precise cutting between clips a lot harder.
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.
Oh, I agree. I was just wondering whether you thought about it and I guess you have. BTW Google Page Speed's biggest complaint for your home page was that images were not served from cookieless domains and downloading them was not paralellized.
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.
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.
I agree with using /bin/bash if that's what you're actually using and aren't sure the script will work more generally.
Something that can help pin down usage of bash extensions is checkbashisms (in the devscripts package on Debian systems). Also running the script through a shell that claims POSIX compliance like /bin/dash.
Also, SA leverages blacklist services (and other techniques, it's very configurable) and is easier to integrate into your mail server.