Thttpd is handling the load just fine. My CPU is 90% idle. The problem is collisions. The two-foot ethernet link from the DSL box to my switch is half-duplex. At the height of it I was getting about 400 collisions/second out of 1500 packets/second. It's tapering off now.
There's no technical reason for it, and they don't start out that way, but nevertheless it's true. Every single RBL is run by weenies, and only weenies pay attention to them.
Hey, at least it didn't make the other icons move all over the place, like some other versions of this idea that I've seen. Those are *impossible* to use; this one was merely annoying.
You're benchmarking CPU and physical memory operations there. There's not going to be much difference with any OS on those. Where FreeBSD wins is in things like network & disk I/O, virtual memory, context switching, etc.
It's not just compatible, it actually runs Linux programs faster than Linux does.
Re:"Client server is slow" myth dispelled, once mo
on
X.Org 6.8.2 is Out
·
· Score: 1
Thanks for the history.
I'm actually tempted to try a port of the plain old sample server included in the X11 distribution, that everyone used to use before XFree86. It would be interesting to see how fast it runs on current hardware. I suspect that for what I do, mainly just xterms and firefox, it would work just fine.
I used to port the sample server to each new Sun frame buffer and it was quite easy. You just had to find two numbers: the memory address for the start of the frame buffer, and the memory width of each scan line. Took less then an hour for each new architecture.
I want an API that lets me upload images for printing on demand. I have 7500 images in my photo database and I'm perfectly happy hosting them on my own server; but I also want people to be able to order prints. Uploading all 7500 to ofoto or shutterfly would be a bad idea. What should happen is a viewer clicks on an "Order Print" button on my site, and behind the scenes a CGI on my system uploads that file to the service and then redirects the viewer to a page where he or she can place an order. The service handles billing, printing, and shipping, and also sends me a percentage.
The flash usage is just one of many things about flickr that I can't take. It could potentially be great, if they removed about 80% of the features and fluff.
I'm currently using http://www.fotothing.com/. It's nice and simple, like fotolog, but without fotolog's 500,000 Brazilian camgirls and ridiculously bad performance.
I find that flickr actually has too many features. It's hard to which of the dozens of different pages you need to go to in order to do what you want to do. Also, it's kind of ugly, which is important for a visually-oriented site.
Fotolog was nice and simple, just the right level of functionality, before it got overwhelmed by Brazilian camgirls. These days I use http://www.fotothing.com/ which is similar, has a few more features, but is just getting started. Only 200 users so far. Sign up now, get the userid you want!
Yes, that's the idea. You would run sendermilter *after* spfmilter. First spfmilter rejects mail trying to use an smtp-sender that it is not authorized to use. Then on the mail that gets through that check, sendermilter would see if the header-sender inside the message matches the authorized smtp-sender. If it doesn't, the message is still accepted but it gets marked as possibly forged.
Microsoft's patent covers checking the header-senders in a particular order. If you've been following the patent discussion you should know that there are plenty of other programs that check in other orders. If you're worried about the patent (I'm not), then just don't use Microsoft's particular order.
The one feature of Sender-ID that I'd like to see in SPF is checking the header-sender as well as the SMTP-sender. Of course this is expensive, requiring reception of the message body, but it's worth it.
It occurred to me recently that I could write a separate milter to implement just this one check. It would compare the SMTP-sender against the header-sender, and if they don't match then it would add a header to the message saying "possibly forged". A later step in the delivery process, such as bogofilter, would see this header and weigh it appropriately.
SPF is well-defined, widely-deployed, and works great. Well, not against spam - most spammers use stolen zombie machines and don't bother forging the sender address. SPF does work quite well against worms & viruses. It has helped me cut down on my inbound malware bandwidth use tremendously.
I don't think it would be very hard to adapt SPF implementations so they also check the body From: header, as well as the envelope MAIL FROM sender. Maybe just check that the two match, and if they don't then add some sort of "may be forged" header. Not a very big deal. Let's ignore Microsoft and just do it.
Oops, sorry, the astronomer's name was not Walter Sullivan. That of course is the name of a science reporter - he wrote an article about the supposed maser observations. I forget the name of the actual astronomer.
Yeah, it's silly. In fact our civilization will keep on radiating more and more RF until we have fully saturated the airwaves with encrypted spread-spectrum signals from trillions of separate low-power sources. To an outside observer this would basically look like thermal noise peaking at microwave frequencies.
SETI@Home and other SETI searches skip right past sources like this, but guess what: ten years ago an astronomer named Walter Sullivan wrote up his observations of intense thermal microwave emissions from four nearby start that are otherwise similar to our sun. He attributed it to natural stellar masers, which do exist in other types of stars. I say he made the first observation of another civilization.
I've been doing this for a few weeks now and it works great. I run clamav to initially recognize the worms. I keep the blockage for a week, though, not 24 hours, and I block for just one worm, not two. This may explain why my numbers come out better than these virbl folks - before IP blacklisting, worms were using up almost half my 1.5 Mbps incoming bandwidth; now it's down to around 15%.
Slashdot Mirror
Ooo, good point. PIPELINING is now disabled on acme.com. Thanks!
Hardware info here. It's a 3.2 GHz P4. I was struggling along on a 450 MHz box until only a year ago, but finally had to upgrade.
Thttpd is handling the load just fine. My CPU is 90% idle. The problem is collisions. The two-foot ethernet link from the DSL box to my switch is half-duplex. At the height of it I was getting about 400 collisions/second out of 1500 packets/second. It's tapering off now.
There's no technical reason for it, and they don't start out that way, but nevertheless it's true. Every single RBL is run by weenies, and only weenies pay attention to them.
Hey, at least it didn't make the other icons move all over the place, like some other versions of this idea that I've seen. Those are *impossible* to use; this one was merely annoying.
>it works by the concept of reducing light scattering.
Isn't this called "black"?
You're benchmarking CPU and physical memory operations there. There's not going to be much difference with any OS on those. Where FreeBSD wins is in things like network & disk I/O, virtual memory, context switching, etc.
>it's fully binary compatible with Linux
It's not just compatible, it actually runs Linux programs faster than Linux does.
Thanks for the history.
I'm actually tempted to try a port of the plain old sample server included in the X11 distribution, that everyone used to use before XFree86. It would be interesting to see how fast it runs on current hardware. I suspect that for what I do, mainly just xterms and firefox, it would work just fine.
I used to port the sample server to each new Sun frame buffer and it was quite easy. You just had to find two numbers: the memory address for the start of the frame buffer, and the memory width of each scan line. Took less then an hour for each new architecture.
Just what is the scaling behavior of RSS, anyway?
I want an API that lets me upload images for printing on demand. I have 7500 images in my photo database and I'm perfectly happy hosting them on my own server; but I also want people to be able to order prints. Uploading all 7500 to ofoto or shutterfly would be a bad idea. What should happen is a viewer clicks on an "Order Print" button on my site, and behind the scenes a CGI on my system uploads that file to the service and then redirects the viewer to a page where he or she can place an order. The service handles billing, printing, and shipping, and also sends me a percentage.
The flash usage is just one of many things about flickr that I can't take. It could potentially be great, if they removed about 80% of the features and fluff.
I'm currently using http://www.fotothing.com/. It's nice and simple, like fotolog, but without fotolog's 500,000 Brazilian camgirls and ridiculously bad performance.
I do like some Flickr features, such as tags.
I find that flickr actually has too many features. It's hard to which of the dozens of different pages you need to go to in order to do what you want to do. Also, it's kind of ugly, which is important for a visually-oriented site.
Fotolog was nice and simple, just the right level of functionality, before it got overwhelmed by Brazilian camgirls. These days I use http://www.fotothing.com/ which is similar, has a few more features, but is just getting started. Only 200 users so far. Sign up now, get the userid you want!
Change it to linux in general and it would be just as true.
Unbelievable. I'm not completely opposed to software patents but this sure is a great example against them.
Yes, that's the idea. You would run sendermilter *after* spfmilter. First spfmilter rejects mail trying to use an smtp-sender that it is not authorized to use. Then on the mail that gets through that check, sendermilter would see if the header-sender inside the message matches the authorized smtp-sender. If it doesn't, the message is still accepted but it gets marked as possibly forged.
Microsoft's patent covers checking the header-senders in a particular order. If you've been following the patent discussion you should know that there are plenty of other programs that check in other orders. If you're worried about the patent (I'm not), then just don't use Microsoft's particular order.
The one feature of Sender-ID that I'd like to see in SPF is checking the header-sender as well as the SMTP-sender. Of course this is expensive, requiring reception of the message body, but it's worth it.
It occurred to me recently that I could write a separate milter to implement just this one check. It would compare the SMTP-sender against the header-sender, and if they don't match then it would add a header to the message saying "possibly forged". A later step in the delivery process, such as bogofilter, would see this header and weigh it appropriately.
I'm interested in comments on this idea.
Oh come on, you could at least have gotten someone else to trade nominations with you. For instance, me!
SPF is well-defined, widely-deployed, and works great. Well, not against spam - most spammers use stolen zombie machines and don't bother forging the sender address. SPF does work quite well against worms & viruses. It has helped me cut down on my inbound malware bandwidth use tremendously.
I don't think it would be very hard to adapt SPF implementations so they also check the body From: header, as well as the envelope MAIL FROM sender. Maybe just check that the two match, and if they don't then add some sort of "may be forged" header. Not a very big deal. Let's ignore Microsoft and just do it.
Oops, sorry, the astronomer's name was not Walter Sullivan. That of course is the name of a science reporter - he wrote an article about the supposed maser observations. I forget the name of the actual astronomer.
Yeah, it's silly. In fact our civilization will keep on radiating more and more RF until we have fully saturated the airwaves with encrypted spread-spectrum signals from trillions of separate low-power sources. To an outside observer this would basically look like thermal noise peaking at microwave frequencies.
SETI@Home and other SETI searches skip right past sources like this, but guess what: ten years ago an astronomer named Walter Sullivan wrote up his observations of intense thermal microwave emissions from four nearby start that are otherwise similar to our sun. He attributed it to natural stellar masers, which do exist in other types of stars. I say he made the first observation of another civilization.
I've been using the equivalent in GIF for years, but I had to write a custom program to create the file. No image editor could do it.
I guess I could adapt the program for PNG.
I've been doing this for a few weeks now and it works great. I run clamav to initially recognize the worms. I keep the blockage for a week, though, not 24 hours, and I block for just one worm, not two. This may explain why my numbers come out better than these virbl folks - before IP blacklisting, worms were using up almost half my 1.5 Mbps incoming bandwidth; now it's down to around 15%.