Frankly, I'm surprised the percentage isn't higher if the sites are badly maintained enough to let this guy in through another exploit.
341 karma · joined February 4, 2009
If you've got a site you're struggling to scale, we can help. http://bashton.com/
Frankly, I'm surprised the percentage isn't higher if the sites are badly maintained enough to let this guy in through another exploit.
I'm excited to see what innovations come out of this. Of course, this will only become really interesting when there are other providers doing the same.
http://www.datacenterknowledge.com/archives/2009/04/15/teleh...
Using a vendor-supplied kernel means that there are extremely likely to be other people using most of the same stack as you, many of them on the same hardware. If there are problems, it's likely that other people have noticed the issue, even if the bug hasn't been found, so it's much more likely to get fixed.
If you compile your own kernel (and/or copy of Apache, MySQL etc etc) you're running something unique to you. If you have problems, you're on your own.
If you're paying for Red Hat Enterprise, use the Red Hat Enterprise packages unless there's a good reason not to. If something goes wrong, you can call Red Hat support and have at least a steer in the right direction. Custom-compiling everything just for the sake of it, just to have new 'shiny' stuff is crazy.
Videos like this are the answer they came up with. Unsurprisingly it looks plasticy and fake, because they're trying to fake something that has grown spontaneously elsewhere.
I have two ZyXEL home plug devices and get ~ 60-70Mbps from them (they're rated at 200Mbps for the whole network you can add them as you go). They're pretty good, but latency is higher than I'd expected - ~4ms.
Frankly, if the N97 only ran Android and had a better touch screen it'd do most of what this article recommends.
All modern Linux distributions - RHEL, SuSE, Ubuntu and yes Debian too have packaging formats to handle dependencies. It's up to the distributions to package the apps, as a software developer I think you should be shipping just a plain tarball, which lists its dependencies but doesn't include them.
My main point was the idea that Django apps shouldn't have dependencies is wrong. Django is awesome mainly because of the ability to easily build on other apps. Doing this creates dependencies, and there's nothing wrong with that.
The package explicitly specifies the dependencies. I agree custom installers are a very bad idea, but you seem to be arguing against the very idea of having dependencies, which seems crazy to me.
When I first started using PHP god knows how long ago (IIRC PHP 4 was still in beta), one of the things that shocked me was that there was no equivalent to Perl's CPAN. Things are better now, but not that much, and beyond DB libraries there is still far too much reinvention of the wheel in PHP.
Django is very much in the Unix philosophy of code re-use, and anytime you re-use code there are going to be dependencies. Added to this, many apps are going to use Python, non Django-related libraries, creating more dependencies. Any good Django app that's doing anything moderately complex should have a pretty long list of INSTALLED_APPS.
Many rails apps work with a simple untar because they include their libraries in vendor. I'm not a ruby guy, but Luke Kanies (creator of puppet) is, and wrote a great post on why this is stupid - see http://www.madstop.com/ruby/ruby_has_a_distribution_problem....
Basically what I'm saying is don't fear dependencies, embrace them.
For http://kutoken.com/, our Django hosting service, we've spent quite a while packaging Django apps into .deb format, so our users can for example just 'apt-get install python-django-tagging' to have tagging support in their app (for a really simple example). Now I've got used to working with a system like that, I really couldn't go back to individual tarballs and setup.py and the like.
I've yet to see a compelling reason to use Chef rather than Puppet, but maybe I've just not been looking hard enough. Puppet is great, and we're a Python shop..
They did this for one reason plain and simple: competitive advantage over VMWare.
I'm really interested to see how TrafficServer stacks up compared to Varnish.
Now I used Varnish, and it's awesome. Far more powerful than Squid, and massively better performance too. Want to drop cookies from some requests/replies? Simple. Want to direct some types of traffic to a different set of backends? Simple.
It's possible to do all these things with Squid using external helpers too, but Varnish makes it so much easier, I'd never go back for a reverse proxy cache.
Highlights of our service include a separate MySQL cluster (databases on a VPS don't perform so well) and a proper SLA.
More info at http://kutoken.com/
Anyway, RIP Fravia
TV news stations will of course hype this thing beyond all proportion, as they always do, but that doesn't mean the threat isn't real and that, as the article suggests, the death toll from Swine 'flu itself won't run into tens if not hundreds of millions.
Similarly, anyone naive enough to believe that "Any skills, staff, source code, infrastructure, and solutions you invest in any Unix are portable across IBM, Sun, Fujitsu, HP, Apple, and generic 32- and 64-bit x86 hardware." really shouldn't be placed in a position where they have any say over platform choice.