Slashdot Mirror

Your question feels a bit of strange question to ask as surely anyone who has looked would notice a huge difference between the latest 2.6 (2.6.28) and the latest 2.4 (2.4.37).

Preemptible kernel (so lower latencies are possible)
Far more devices supported (both in terms of architectures and additional add on devices e.g. SATA support)
Better scheduler (initially made O(1) scales better under load and then fairer with CFS)
Task Control Groups
Better support for threads (schedules them in a more intelligent fashion)
Strict overcommit
Massive VM changes
Tickless/dynticks support
Asynchronous I/O support
Introduction of different I/O schedulers (deadline, cfq
Network stack improvements (faster, better under load e.g. NAPI support)
epoll support
Improved ACPI support
Network filesystem improvements
Initramfs support

There is a huge list of Linux kernel changes that happened between 2.4 and 2.5. There is also a good Linux kernel 2.5 changes page on IBM's developerworks. Kernelnewbies has an excellent summary of changes for each of the 2.6 kernels and a 2.5 changes page. LWN is also excellent for kernel news.

I hate it when people don't bother to state exactly the points they object to. What other changes (not listed above) do you think the question poster wouldn't benefit from? Follow the links to the full lists (don't just use the ones off the top of your head)...

The more effective way I have found to stop spam is grey listing. In the last two months, I have had zero spam messages go through to my mail server. I use GSLT (http://www.xmailserver.org/glst-mod.html), which is mostly for the XMail mail server ( http://www.xmailserver.org/) but will work anywhere.

You should also check this article http://www.freesoftwaremagazine.com/articles/focus _spam_postfix?page=0%2C0, lots and lots of good advice on spam filtering.

The more effective way I have found to stop spam is grey listing. In the last two months, I have had zero spam messages go through to my mail server. I use GSLT (http://www.xmailserver.org/glst-mod.html), which is mostly for the XMail mail server ( http://www.xmailserver.org/) but will work anywhere.

You should also check this article http://www.freesoftwaremagazine.com/articles/focus _spam_postfix?page=0%2C0, lots and lots of good advice on spam filtering.

That's a cool project for a Windows honeypot. Thanks for the link. Outside of honeypots, I've been blanket filtering addresses from APNIC on my mail server for about a year now using some ideas I learned from this project (I filter at the mail request level rather than iptables). It's sad to filter an entire geographic region like that, but my users never talk to people from the Pacific Rim that I know of. My server (running XMail) is small, but my logs for the filtered emails constantly show the spam blocked exceeds the number of legit mails by a factor of four.

I am not the original poster, but I can give you some examples too. I had worked with Sendmail, Qmail, Postfix, Exim, Xmailserver and Zmail. I needed SMTP-AUTH and virtual users, virtual domains, same user names different domains etc. The last time I touched sendmail was version 8.12.something I guess, I was able to configure Sendmail the way I wanted after spending lot of time reading, it worked for me but I decided to try some other MTAs as well. I was abler to do the simular configuration with Qmail, I was not able to do it with Exim and Postfix, but to be quite honest I didn' spend much time with them. Didn't spend much time with Zmailer either. Then I have discovered Xmail. This thing is awesome!!!! It is all in one package and it is very easy to configure, it has a lot of add-ons. I have been using it for more than 2 years, never had a single problem. I did install from tarball archive not from RPM. I dont' recommend using RPM archives. http://www.xmailserver.org/

Try this:

http://www.xmailserver.org/linux-patches/nio-impro ve.html /dev/epoll

The website is hideous, but there used to be benchmarks against different polling/selecting methods. If I remember correctly, its kinda trial and error, YMMV, kind of stuff. Its worth a look.

You're joking right? Ever heard of epoll()?

I just add a bit on that list from top of my head.
Although I think the listed app goes beyond what the so called 'average pc user' wants, but there goes...

1. Konqueror ( http://www.konqueror.org/ )

2. Email - Sylpheed ( http://sylpheed.good-day.net/ )

3. I think Evolution is more like in this place.

4. Lately "Sound Juicer" is taking more attention too

5. VideoLAN aka VLC ( http://www.videolan.org/ ) and Ogle ( http://www.dtek.chalmers.se/groups/dvd/ ) [and Goggles ( http://www.fifthplanet.net/goggles.html ) for Ogle GUI wrapper] for DVD watching.

6. There are plenty way to do this, but the typical ones could be 'Jinzora' ( http://www.jinzora.org/ ) and 'MusicPD' ( http://www.mpd.org/ ), even plain Apache does it fine too, in a way.

8. If you want easier to manage iptables wrapper, Shorewall ( http://www.shorewall.net/ ) and there are other wrappers too.

9. KOffice ( http://www.koffice.org/ ) and by individual components, Abiword ( http://www.abisource.com/ ), Gnumeric ( http://www.gnome.org/projects/gnumeric/ ), Gnucash ( http://www.gnucash.org/ )

10. Inkscape ( http://www.inkscape.org/ ) or Sodipodi ( http://www.sodipodi.com/ ) for vector graphics.

11. Miranda ( http://miranda-im.org/ ). Windows only.

13. Hmm , Samba? ( http://www.samba.org/ ), WedDAV (Look parent post), FTP (plenty ftp daemons, ex : http://www.proftpd.org/, http://vsftpd.beasts.org/ etc)

16. GPhoto ( http://www.gphoto.org/ ), EOG ( http://www.gnome.org/ ? ), GQView ( http://gqview.sourceforge.net/ ). The latters are for just viewing mainly.

20. FreeNX ( http://www.nomachine.com/ , http://freenx.berlios.de/ ) http://www.poptop.org/ ), L2TPd ( http://sourceforge.net/projects/l2tpd ), RP-L2TPd ( http://sourceforge.net/projects/rp-l2tp/ )

24. Postfix ( http://www.postfix.org/ ), Sendmail ( http://www.sendmail.org/ ), Exim ( http://www.exim.org/ ), Cyrus ( http://asg.web.cmu.edu/cyrus/imapd/ ), Xmail ( http://www.xmailserver.org/ ), qmail ( http://www.qmail.org/ )

25. Spamassassin ( http://spamassassin.apache.org/ )

26. Same as above.

27. XSane ( http://www.xsane.org/ ) for sane frontends.

30. Buzzmachines ( http://www.buzzmachines.com/ ) I could be wrong...

31. 'various GUI frontends' - X CD Roast ( http://www.xcdroast.org/ ), K3B ( http://k3b.sourceforge.net/ )

32. Don't know any opensource ones...

kqueue is in FreeBSD since 4.1 or, at least, April 2000. epoll was first introduced into Linux-2.5.x (when exactly?)

The initial version started in December 2001. epoll in its present form was added to the base kernel in 2.5.45, October 2002.

and is still not present in production kernels

Wrong. It's in every 2.6-based distro, which is most of them right now, and for the "commercial enterprise class" users that includes Red Hat Enterprise Linux 4 and SuSE Linux Enterprise Server 9.

Linux' failure to implement a known, well documented and exemplified, freely available API, which predates Linux' own solution by several years, is the gist of my complaint.

I know the gist of your complaint, but kqueue really was considered during the design of the current epoll, and was rejected. Looking at the kqueue documentation now, I think Linus was right to reject it.

The ideas underlying kqueue are good, but the implemented API has flaws. Take a look at the documentation, and ask: Can you wait for reading/writing on a terminal file descriptor? What about an audio device? A serial port? The answer is not according to the documentation, yet it ought to be possible to wait on an any file descriptor with the same meaning as select/poll.

The initial versions of /dev/epoll had the same flaws and others. But that was rejected too, and it had to be changed to the epoll you see today before it was accepted.

epoll isn't perfect. In fact I argued for a more general event-waiting API at the time, but Linus likes simplicity, and that's what we have now. It is nice and simple to use. It's major ommision is that it doesn't play well with AIO, and that will have to be solved eventually.

Your mistake is trying to map a write-only file. It's not permitted because the CPU is not capable of write-only pages, so all write-only mappings are really read-write mappings. If BSD is letting you map a write-only file on the same kind of CPU, that's a security hole in BSD.

Nice theory, but wrong. Try exploiting it. Unless you open with O_RDWR (or O_RDONLY), you can not mmap with PROT_READ (EPERM). And if you don't mmap with PROT_READ, you can not, well, read (SIGBUS).

It's you who are wrong on this. Ok, let's try exploiting it.

I've mapped a write-only file with PROT_WRITE only (not PROT_READ), opened with O_WRONLY. The file is write-only: it has permission 0200 (--w-------), and it can't be opened for reading or read-write: verified by "cat test_mmap_file" correctly saying "Permission Denied" and other ways it cannot be read.

Then I read from the mapping and printed what was read, to prove it was really reading the file's contents. I tried both a local file in /tmp, and also a file over NFS. Results:

FreeBSD 5.3/i386: I can read from the write-only file using mmap.
NetBSD 2.0/i386: I can read from the write-only file using mmap.
FreeBSD 5.3/Alpha: I can read from the write-only file using mmap.

Well, well, the exploit works. You should really test a feature before arguing about it. :)

Tsk, a security hole in the current production versions of FreeBSD and NetBSD no less. :) [It's unlikely to have major consequences, though, as write-only files are rarely used and never for anything critical.]

The results for i386 are no surprise, as the CPU itself is incapable of write-only mappings. (It's a bug that BSD let's you map a write-only file at all, but given that it does then it's not surprising you can r

For file descriptor events, Linux has a better implementation than kqueue, called epoll. It's better because it works with all types of file descriptor (thanks to using the same kernel functions as poll/select internally), not just the subset documented in the kqueue man page. Which means you can use epoll in a generic replacement for select/poll, which you can't quite do with kqueue.

kqueue can do other things, including aio which is useful, and it is marginally more efficient due to fewer system calls for registration, but the documented file descriptor limitations are a weak point so it should not be copied exactly the same into Linux. It is possible to add the other things that are useful from kqueue to epoll, but nobody has done so. Perhaps there isn't much demand for it.

mmap: you can grow files while using mmap on them. That's what ftruncate and mremap are for. Oh, did you want to grow files automatically to the nearest rounded-up page when you write to a page beyond the current size? That's not as useful as it sounds, because typically you must still check against a bound, otherwise you'll write beyond the end of the mapping's virtual address. Given that you must have that check, you can easily check against a smaller bound instead and call ftruncate when you're about to exceed it, plus mremap to arbitrarily extend the mapping, which is better than limiting yourself to a fixed maximum size with mmap in advance.

And if you don't want to allocate disk blocks: ftruncate creates a sparse file, the disk blocks are allocated on demand when you write to individual mapped memory pages.

Enjoy,
-- Jamie

There's epoll and AIO
There's no need for that (kqueue) bloated interface in Linux

Amail, Bmail, Cmail, Dmail, Email, Fmail, Gmail, Hmail, Imail, Jmail, Kmail, Lmail, Mmail, Nmail, Omail, Pmail, Qmail, Rmail, Smail, Tmail, Umail, Vmail, Wmail, Xmail, Ymail, and Zmail

Sorry.

Davide Libenzi of Xmail Server and Many other great projects is my hero of OSS.

To bad I didn't see this posting sooner.

...Either way, in order to implement the proposal the MTA authors will have to do some work, and I don't think there's much to choose between the two...

• dnsmasq - A DHCP+DNS server that is simple to configure, lets you set up names for local machines and local services, lets you block external names of your choice, etc, etc
• masqmail - A mail server for machines with intermittent connections to the internet (dialup, laptops, wireless)
• Xmail - A slightly bigger mail server for when you want to run your own domain. Linux and Windows.
• Icewm - The window manager for people who want to get their work done
• Bluefish - Text/HTML/Perl/PHP/Java/etc editor that just works.

Let's see. . something good like kqueue...

http://xmailserver.org for hosting multiple sites. Small, flexible, easy to set up, and relays mail by default(3 out of 4 ain't bad)...

I'm not trying to start a "my MTA is better than your MTA" war, but for those of you who
are like me and got tired of trying to figure out sendmail, you should give XMAIL a shot
It is both a SMTP and POP3 server, will soon support IMAP, and has been incredibly reliable and easy to
set up for me, YMMV.

Well.. they are including among other things epoll() which should scale well for thousands of clients. It serves the same purpose as select() and poll() but works a bit different.

OK, I'm not a Linux man: but I didn't think Linux actually supported proper asynchronous I/O. And the acryonym, for better or for worse, is still LAMP and not FAMP or SAMP (or even SAOP). (WISA, anyone? :-) ) Sure, you can pass a shed-load of sockets into a select() call but I can't see select()'s efficiency being even close to linear in set size.

Linux does not support the POSIX AIO interface with a standard kernel (SGI has an implementation available). The supported Linux method is realtime signals. While there is probably a good reason that they chose this non standard, Linux specific method (besides the "because we can"), I haven't seen anything documenting the reasoning.

Another method, /dev/epoll, is somewhat similar to Solaris' /dev/poll. It is more efficient and has (IMHO) a cleaner interface than the realtime signals. Hopefully this patch will make it into the mainstream kernel.

The following page is an excellent reference on I/O models: http://www.kegel.com/c10k.html

I would definitely recommend XMail Server. Cross platform (Linux, FreeBSD, WinNT/2K/XP, Solaris), runs multiple domains with no problem. Not really that hard to set up if you read all the docs. There are several web config apps for it now and it's not that hard to program against the TCP config interface. It's being actively developed (new release every month or more often if a rare bug comes up.) It's licensed under the GPL. I use it with about 30 domains with 4-20 users per domain. I have had 0 problems with it. Easy to use, easy to upgrade (just copy the new binaries) no complaints.