Slashdot Mirror

Anybody I know who's still there is using GigaNews or one of the other premium services.

I talked my ISP into giving me a /29 netblock in exchange for hosting their newsfeed. I set up a copy of Leafnode-2 in a FreeBSD jail and pointed it at some public servers. Very few other customers use it and they subscribe to text groups, so the traffic overhead is negligible for me.

Does anybody run an ISP mail system with Qmail featuring predominately as MTA of choice?

At my previous job we used to run qmail for our mailhosting boxes. I can tell you that we were really happy with qmail back then, with the right patches it can be a really flexible mailserver, and once you're used to how it works you'll be in SMTP bliss. However, when you need functionality that isn't provided by qmail, you're doing one (or some) of the following:

• patching qmail, recompiling, testing, deploying
• writing a perl/bash/whatever script that goes somewhere in the Big Qmail Picture
• muttering curses and djb's name for the licensing

I can't really bring myself to bashing qmail over these things because it's served me well and I've hardly had any "unexpected" things happen to me, which is something I can't really say of other MTAs I've tried and I've never had any security problems (altough you might want to read this page). There's a lot of information available on qmail, and you can check out this guide (although this may now be quite dated). An indispensible tool is qmHandle for inspecting and manipulating the qmail queue in case something did go wrong.

Finally, I have to admit that when I left that company my own mailhosting services are currently being run by postfix, simply because I don't have the time to build my own qmail packages whenever I need some feature. If you look at the postfix design, any qmail user will see similarities and the fact that you're not patching and rebuilding it whenever you need feature X sort of grows on you.

I know that if I were to start hosting a large mailserver, I'd have a hard time deciding between the two and I'd do a lot of testing before I made a choice.

Ho humm, is qmail really that great? A lot of what DJB writes makes sense, but he seems to have a whole bunch of zealot followers who will flame you to death if you rise any questions about qmail stability/security. While some of the points in http://www.dt.e-technik.uni-dortmund.de/~ma/qmail-bugs.html are near the point of irrelevance, it certainly still doesn't give me a lot of confidence in qmail.

Qmail is secure by nature. Qmail is guaranteed by the programmer to not have security bugs, with a $500 bounty for the reporter of the first exploit.

Ars has an article exploring why it's hard to program such GPUs for anything other than graphics applications.

No, Ars has an article blithering that it's hard to program such GPUs for anything other than graphics applications. It doesn't say anything constructive about why.

Here's an reasonably readable tutorial on doing number-crunching in a GPU. The basic concepts are that "Arrays = textures", "Kernels = shaders", and "Computing = drawing". Yes, you do number-crunching by building "textures" and running shaders on them. If your problem can be expressed as parallel multiply-accumulate operations, which covers much classic supercomputer work, there's a good chance it can be done fast on a GPU. There's a broad class of problems that work well on a GPU, but they're generally limited to problems where the outputs from a step have little or no dependency on each other, allowing full parallelism of the computations of a single step. If your problem doesn't map well to that model, don't expect much.

Using the basic math tutorial, I've measured up to over 6000 FLOPS for the GPU of a Quatro FX 4500 card.

Google "Dominik Goeddeke" and read his GPGPU tutorial. It's excellent, as far as tutorials go, and helped me bootstrap.

Ok, ok, here's the link...

First: Correlation is (as the name indicates) a relation, and relations are transitive: If A relates to B, and B relates to C, then A relates to C too. This is per definitionem, no point worth arguing about. The correlation just multiplies.
Second: The relations Low Income -> Obesity risk and Low IQ -> Low Income are well known for Central Europe, not just some questionable studies (If you understand German, check out Walter Kraemer's work, especially about "Gesundheitswesen" (Public Health) and "Armut" (Poverty). Sorry. There is no mainly English speaking country in Central Europe, so studies there often are not in English :)
Third: The causality I was noting was just an example for a possible explanation, and it has to be checked if it is real or just another coincidal correlation. At least it seemed to me more intuitive than a direct causality Obesity -> Low IQ.

Double arithmetics can be emulated with single floats, also on GPUs. But such emulations increase more than tenfold the operation count. This is only acceptable in otherwise bandwidth bound operations.

In this paper we, therefore, propose the revitalization of mixed precision defect correction approaches that have been known for almost 100 years: By iteratively computing residuals of a single precision approximate solution to a linear system in double precision, only few correction steps suffice to reduce approximation errors close to machine accuracy. In the context of scientific computing using GPUs, this approach translates to correcting a GPU result with just a few CPU-based iterations. In this way we obtain the full accuracy of CPUs with the high speed of GPUs.

OK, I'll indulge you. Why sendmail sucks, in a nutshell:

It was designed before Internet e-mail standards were established. As a result, it contains a general purpose rewriting engine that's Turing complete--the idea was it would be able to be configured to translate addresses between BITNET, UUCP, JANET, ARPAnet, CompuServe, FidoNet, and so on, without recompiling the sendmail binary. This was important because back in the 80s, those networks all had different address formats.

Nowadays the ability to arbitrarily rewrite addresses is completely unnecessary, but Sendmail keeps the old design. This leads to a number of major misfeatures.

1. Sendmail is a pig to configure. The "new improved" sendmail.mc is slightly better than the old sendmail.cf, but still awful compared to the alternatives because it's layered on top of M4, an ancient macro processor. Compare an example postfix config and an example sendmail config. And remember, that's the new .mc file that's compiled into the actual sendmail.cf; if you ever need to do something complex that requires editing the sendmail.cf itself, you'll be faced with something much nastier.

2. Sendmail has a continuing history of poor security. 16 vulnerabilities between 2000 and mid-2006, according to nvd.nist.gov. By comparison, Exim has had 9, Postfix has had 4, Qmail 3.

3. Sendmail has lousy performance. Postfix is 2-4x faster. Take a look at some benchmarks.

4. Sendmail was designed to parse and reconstruct the header of every e-mail going through it. This makes it brittle--give it something it isn't expecting, and the results are unpredictable. This has resulted in Bcc:ed recipients being revealed to each other, unknown header fields being destroyed, and so on. It also makes e-mail forensics difficult--just because the message looked like it had the right addresses when it arrived, didn't mean it had the right addresses when it was sent, if it has passed through sendmail. MTAs should not rewrite e-mail going through them; only e-mail being passed to them directly by a client.

5. It has broken behavior when sending to multiple recipients. For example, if the To: field is missing a comma between two addresses, sendmail will send copies of the e-mail to all the addresses that it can parse, then barf on the broken ones. This is unhelpful, because if the user then re-sends the mail, most people end up getting 2 copies.

So in short: it's broken, it's slow, it's insecure, and it's awkward to configure. There are other open source mailers that have a few of those defects, but sendmail is the only one that has them all. Do a search for "sendmail sucks" and you'll find plenty of people with the same opinion as me.

You are making a completely invalid assumption. The assumption you make is that all software will always have bugs. This is provably untrue. When software is designed against such failure, then it is likely that they will accomplish that end. An example of this is QMail. (check here for the only ones I could find)

This isn't meant to bash any project in particular, but the fact remains that a program is a series of instructions and the computer folows them. It is possible to write a series of instructions that does not present vulnerabilities to attackers. If a utility or library has problems, the utility or library should either be fixed or avoided. It's POSSIBLE. It always has been and always will be. To suggest that there are impossibilities such as this would be the same as saying it's impossible to quit smoking or doing drugs -- it may be difficult or even painful to do, but it remains in the realm of possible. It them becomes a question of whether or not a programmer chooses a more difficult challenge.

Sombody asked for some videos of Robosoccer matches, unfortunatly i could not find any of the 2005 World Cup but some nice aolder ones:

http://www-ds.e-technik.uni-dortmund.de/~robotics/ content/videos.html

Have fun ...

I remember that one. It was two papers, one about "radiosity in an enclosed space with no internal light sources" or some such thing. (of course, the problem is trivial). The other was about footprints and actually sounded kind of interesting, though entirely silly. Both were accepted.

Here's a link:
Fake VIDEA papers

...more than a couple bugs...

Many of the "bugs" listed above are arguable, and frequently disputed by qmail users and opponents. That is, many of them could not be a reason to single-handedly strike down qmail itself.

As an example.. From the above document:

All the contents of this document refer to qmail-1.03.

4.3. Bandwidth hogging (violates RFC-2821 SHOULD clause)

So.. qmail 1.03 was released in June 1998, RFC 2128 was released in April 2001. I'm inclined to say that calling this a "violation" is not that fair. Even more so if you consider that it might have been included in the RFC *in response* of qmail's behaviour by *ahem* some lobbyists. In contrast, qmail's behaviour was explicitly chosen by its author, and he directs anyone who claims this is "hogging", that they should "measure, not speculate" of the implications of the behaviour. What did he get?

And, allow me to say, in my opinion, a "SHOULD" clause is not violated if the "full implications" are "understood and carefully weighed", which has apparently happened.

So, what meant is, the picture is not so clear, you should not believe anything you hear or say on the internet... Not even about qmail.

Sure, no one has found any bugs Knuth's TeX in years. Same for Qmail, and others.
Er, wrong. qmail has had a couple of security flaws, and more than a couple of bugs. For a more exhaustive list, Google is your friend.

http://www-ai.cs.uni-dortmund.de/DOKUMENTE/malzahn _2003a.pdf

Basically, the thesis evaluates different methods to build a kind of "finger-print" of a page. The finger print is used to find the page with google if it is gone, or has changed significantly.

The internet wayback machine was used to learn distinguishing disappeared pages from pages changing slightly over the time.

Man, I can't believe they didn't used radiosity to render those images. Yes, I know it takes a lot more of CPU power, but I would surely steal other people computers just to play Quake that way :)

With version 2.0, UML is going to make an enormous step towards visual application design. Several ambiguities are resolved. Class diagrams and OCL are now built on precise foundations (set theory and predicate logics) [1] -- instead of having most of the semantics described in plain English; the fundations of other diagram types were also formalized.

The advantages of more precise models are that they can better form the basis for code generation [2] or even direct interpretation [3,4]. In contrast to earlier approaches to code generation, a common standard now allows interchange between different tools (at least to some extent).

Here, one of the main advantages is probably not "point and click", but a higher level of abstraction: current programming languages simply do not support high level diagram elements--such as bidirectional associations--as first class members. Things that can be expressed by simple means in class diagrams and OCL expressions become multi-line code in a regular programming languages[5]. Of course, building on UML directly also may resolve maintenance problems such as inconsistencies between diagrams and the actual code.

1. http://www.amazon.de/exec/obidos/ASIN/3897228424
2. http://www.omg.org/mda/
3. http://www.riehle.org/computer-science/research/20 01/oopsla-2001.html
4. http://www-ai.cs.uni-dortmund.de/auto?self=$dq74rv vv
5. http://i11www.ilkd.uni-karlsruhe.de/~baar/oclworks hopUml03/papers/10_combined_model_processing.pdf

Number of security flaws acknowledged by DJB, you mean? It might hurt your religious feelings, but even the holy qmail is not perfect.

Although that page does list various bugs and idiosyncratic, intentional RFC violations by DJB, it is still quite noteworthy that the only security issues involve resource exhaustion and delayed bounces, and the resource exhaustion attack can be fixed with ulimit. One could have left qmail running on a box 4 years ago, and it would not be compromised today, and if someone could reboot it if DOS'd, it would still be working properly. The same can be said for very few other network services.

number of security flaws that have been discovered in qmail (for those sleeping at the back of the class: zero)

(infected machine) -> (your SMTP server)

(infected machine) -> (your SMTP server) -> (bouned mail to server from fake From: header) -> (your SMTP server)

The Qmail author offers money for any holes found. So far he hasn't had to pay a cent.

Not because his software is so good, but because he doesn't agree that DoS vulnerabilities qualify as "holes".

And there are a lot of other reasons not to use Qmail.

To un-necessarily drawl on this topic, it is rather unusual to use review as an adjective. Most people would see a compound noun there: "review copy", with only a single adjective "free". In this view, the comma is incorrect. You can see that is is both correct, yet unusual by this question/answer: "What kind of copy?" - "A review one." Works, but sounds weird.

Ah, the beauty of linguistics.

Really? You should tell this guy what he was doing wrong.

Maybe you should do a little research before spouting off about how there are no useful distributed computing projects out there.

A quick check on Google popped up the following links:

(LILO CRC error...)
http://www.linuxgazette.com/issue50/tag/24.html
http://brenner.chemietechnik.uni-dortmund.de/doc/s db/en/html/kfr_50.html

(Grub cannot fit selected item into memory)
http://www.gnu.org/manual/grub-0.92/html_node/Stag e2-errors.html
http://mm.ilug-bom.org.in/pipermail/linuxers/Week- of-Mon-20020729/005620.html
http://lists.infradead.org/pipermail/linux-mtd/200 0-March/000346.html

Based on those links, I'd be chasing down something taking some of your low memory away from you so that it doesn't boot right. Keep in mind, it may still be an ailing HD as intimated in the LILO links. As for the bootloaders being ready, they are- you've got a special case that's causing you problems and many, many others don't seem to have your issues with them. I can't speak of Red Hat's support since I've not used their distribution in a while- so you may have a beef there.

footnote: (*) easier done in the UK where static IPs are fairly easy to come by compared to some countries - though most proper ISPs are sensible and check you need them first, some, for example the main telco in the country, pretty much force a /29 on the less clueful of their business customers. (The web page is only one side of it, the salespeople seem to be quite good at pushing this option too). Of course: they can then sell personal firewall software and get you to install a second line if you have >5 users. And don't even get me started on their wonderful trick of restricting MAIL FROM: domains at their SMTP relays (and making sure their dynamic ADSL netblocks are listed in the DUL.....

Ye gods -- BBEdit has been able to do that for YEARS! On Emacs, I routinely open files by tunnelling from my laptop, to my server, to another server and open the files remotely that way -- tunnelling through ssh, telnet, or a combination of the two -- (check out TRAMP -- a lovely bit of wonderfullness).

But now that VIM has it?!?! It's a freakin' BREAKTHROUGH!

In addition to ftp, there is ssh/scp support with the tramp package at ftp://ls6-ftp.cs.uni-d ort mund.de/pub/src/emacs/tramp.tar.gz.

The following links may be useful for writing php code in emacs:

• http://funq.org/turadg/software/,
• http://www-publi c.t u-bs.de:8080/~y0008422/krabutzig/emacsphp.html,
• http://www.ontosys.com/reports/PHP.html

Try Exact Audio Copy. It's a Windoze-only app, but it works pretty good, even on badly fscked cd's. It can also use the BladeEnc DLL, Windoze codes or external encoder programs. It has CDDB support too, and it is ``postcardware''.
--

-----

Windows-wise, the best i've found so far is BladeEnc for encoding with EAC. As usual with Windoze software, though, EAC isn't free speech. But it does do a good job ripping...

As for grip, i found it so annoying to use that i went ahead and wrote my own frontend using perl-tk and CDDB.pm from CPAN...

-----