Slashdot Mirror

It sounds like you either did not set something up right - maybe something wrong with your firewall settings (you retarded BSD zealots are always whining about how the syntax is too much for your small brains), or you are just lying because you are a troll.

There are a *lot* of people using IPSec on Linux, including me. "On certain protocols it would just drop packets" just sounds like a vague copout for "I haven't actually tested it and I don't know whether there are any bugs, but this sounds like it's plausible".

If a BSD says something will work in a stable branch, it will work. This is not the case in Linux. 2.6 is meant to be a stable branch, yet a lot of things either don't work or have huge debilitating bugs like this IPSec misfeature. I don't care if Linux' performance runs loops around NetBSD, if it doesn't do what it's supposed to and has no practical workarounds, THIS FAR INTO A STABLE BRANCH, it is not even worth considering.

Sorry, if you think *any* general purpose UNIX operating system is without bugs, then you are seriously mistaken. You obvously have no idea about software development and release engineering process.

No bugs, eh? What about this,
this,
this,
this,

etc. for example, one can easily go to the NetBSD bug database, and find over 700 open bugs marked as high severity and high importance filed against the kernel alone. Many of those are for 1.4, 1.5, 1.6, as well as current.

And, oh dear!! Lo and behold, there are a handful of IPSec bugs in there.

I hope that shuts you up, you stupid driveling idiot.

It sounds like you either did not set something up right - maybe something wrong with your firewall settings (you retarded BSD zealots are always whining about how the syntax is too much for your small brains), or you are just lying because you are a troll.

There are a *lot* of people using IPSec on Linux, including me. "On certain protocols it would just drop packets" just sounds like a vague copout for "I haven't actually tested it and I don't know whether there are any bugs, but this sounds like it's plausible".

If a BSD says something will work in a stable branch, it will work. This is not the case in Linux. 2.6 is meant to be a stable branch, yet a lot of things either don't work or have huge debilitating bugs like this IPSec misfeature. I don't care if Linux' performance runs loops around NetBSD, if it doesn't do what it's supposed to and has no practical workarounds, THIS FAR INTO A STABLE BRANCH, it is not even worth considering.

Sorry, if you think *any* general purpose UNIX operating system is without bugs, then you are seriously mistaken. You obvously have no idea about software development and release engineering process.

No bugs, eh? What about this,
this,
this,
this,

etc. for example, one can easily go to the NetBSD bug database, and find over 700 open bugs marked as high severity and high importance filed against the kernel alone. Many of those are for 1.4, 1.5, 1.6, as well as current.

And, oh dear!! Lo and behold, there are a handful of IPSec bugs in there.

I hope that shuts you up, you stupid driveling idiot.

It sounds like you either did not set something up right - maybe something wrong with your firewall settings (you retarded BSD zealots are always whining about how the syntax is too much for your small brains), or you are just lying because you are a troll.

There are a *lot* of people using IPSec on Linux, including me. "On certain protocols it would just drop packets" just sounds like a vague copout for "I haven't actually tested it and I don't know whether there are any bugs, but this sounds like it's plausible".

If a BSD says something will work in a stable branch, it will work. This is not the case in Linux. 2.6 is meant to be a stable branch, yet a lot of things either don't work or have huge debilitating bugs like this IPSec misfeature. I don't care if Linux' performance runs loops around NetBSD, if it doesn't do what it's supposed to and has no practical workarounds, THIS FAR INTO A STABLE BRANCH, it is not even worth considering.

Sorry, if you think *any* general purpose UNIX operating system is without bugs, then you are seriously mistaken. You obvously have no idea about software development and release engineering process.

No bugs, eh? What about this,
this,
this,
this,

etc. for example, one can easily go to the NetBSD bug database, and find over 700 open bugs marked as high severity and high importance filed against the kernel alone. Many of those are for 1.4, 1.5, 1.6, as well as current.

And, oh dear!! Lo and behold, there are a handful of IPSec bugs in there.

I hope that shuts you up, you stupid driveling idiot.

It sounds like you either did not set something up right - maybe something wrong with your firewall settings (you retarded BSD zealots are always whining about how the syntax is too much for your small brains), or you are just lying because you are a troll.

There are a *lot* of people using IPSec on Linux, including me. "On certain protocols it would just drop packets" just sounds like a vague copout for "I haven't actually tested it and I don't know whether there are any bugs, but this sounds like it's plausible".

If a BSD says something will work in a stable branch, it will work. This is not the case in Linux. 2.6 is meant to be a stable branch, yet a lot of things either don't work or have huge debilitating bugs like this IPSec misfeature. I don't care if Linux' performance runs loops around NetBSD, if it doesn't do what it's supposed to and has no practical workarounds, THIS FAR INTO A STABLE BRANCH, it is not even worth considering.

Sorry, if you think *any* general purpose UNIX operating system is without bugs, then you are seriously mistaken. You obvously have no idea about software development and release engineering process.

No bugs, eh? What about this,
this,
this,
this,

etc. for example, one can easily go to the NetBSD bug database, and find over 700 open bugs marked as high severity and high importance filed against the kernel alone. Many of those are for 1.4, 1.5, 1.6, as well as current.

And, oh dear!! Lo and behold, there are a handful of IPSec bugs in there.

I hope that shuts you up, you stupid driveling idiot.

Is that really what bothers you? I have to report that in spite of the PAM inclusion, NetBSD 3.0-beta is still a world of performance and efficiency, and EVERYTHING works properly. Things that always broke on Linux 2.6.11, for instance.

Sorry, no NetBSD has fundamental problems on anything more than a toy system. Even this so called "big-memory" system is too much for NetBSD's immature memory manager to handle.

But what's the deal with calling that "big-memory"? Maybe for your desktop machine (but in a couple of years it won't be). But for a server? It's amusingly puny. Linux runs fine on machines with 4 - 8 TB of memory.

Oh, and what's this? It doesn't even have basic
realtime scheduling! This is an OS that claims it is good for embedded systems!

It has terrible database performance, even after a multitude of hacks from this kernel developer.

It can't even handle basic SMP CPU topologies like hyperthreading properly. But that's not surprising considering the kernel is completely serialised under a single lock, so why bother making the scheduler any better on multiprocessor systems?

Thanks, but no thanks. If Linux is broken, then NetBSD is a steaming pile.

Is that really what bothers you? I have to report that in spite of the PAM inclusion, NetBSD 3.0-beta is still a world of performance and efficiency, and EVERYTHING works properly. Things that always broke on Linux 2.6.11, for instance.

Sorry, no NetBSD has fundamental problems on anything more than a toy system. Even this so called "big-memory" system is too much for NetBSD's immature memory manager to handle.

But what's the deal with calling that "big-memory"? Maybe for your desktop machine (but in a couple of years it won't be). But for a server? It's amusingly puny. Linux runs fine on machines with 4 - 8 TB of memory.

Oh, and what's this? It doesn't even have basic
realtime scheduling! This is an OS that claims it is good for embedded systems!

It has terrible database performance, even after a multitude of hacks from this kernel developer.

It can't even handle basic SMP CPU topologies like hyperthreading properly. But that's not surprising considering the kernel is completely serialised under a single lock, so why bother making the scheduler any better on multiprocessor systems?

Thanks, but no thanks. If Linux is broken, then NetBSD is a steaming pile.

Is that really what bothers you? I have to report that in spite of the PAM inclusion, NetBSD 3.0-beta is still a world of performance and efficiency, and EVERYTHING works properly. Things that always broke on Linux 2.6.11, for instance.

Sorry, no NetBSD has fundamental problems on anything more than a toy system. Even this so called "big-memory" system is too much for NetBSD's immature memory manager to handle.

But what's the deal with calling that "big-memory"? Maybe for your desktop machine (but in a couple of years it won't be). But for a server? It's amusingly puny. Linux runs fine on machines with 4 - 8 TB of memory.

Oh, and what's this? It doesn't even have basic
realtime scheduling! This is an OS that claims it is good for embedded systems!

It has terrible database performance, even after a multitude of hacks from this kernel developer.

It can't even handle basic SMP CPU topologies like hyperthreading properly. But that's not surprising considering the kernel is completely serialised under a single lock, so why bother making the scheduler any better on multiprocessor systems?

Thanks, but no thanks. If Linux is broken, then NetBSD is a steaming pile.

Actually they have been since 3/26.
http://marc.theaimsgroup.com/?l=nanog&m=1111875859 15504&w=2

There has been quite a lengthy discussion on LKML on that topic. IIRC, there are some issues with NCQ and sound support, but it's an interesting thread well worth reading, if you're into nForce4-thingies that is.

The old 'printer on fire' message wasn't actually an easter egg. Read this for the full story.

Actually, linux scales, and not just on clusters. Some people, like say, the NASA guys, run it on 512 simultaneous processors, people also runs it four, eight, 32 or whatever, and all with the same kernel, not a cluster but a big computer. And of course it musr run estable.

Actually, some of those Enterprises (like cisco or dell) don't have a server OS to say "our option is better, that's why you shouldn't use linux". Why should Dell tell you what you need to run? Linux is the fatest growing server platform, so they should shut up their mouth and working on better linux support if they want to remain profitable.

The one contenders there are Microsoft and Sun. We know that windows don't runs more than 64 cpus so they also should shut their mouth up and work on that. Then there's Sun, who have a real OS, but thinks that Linux is "no loss" for them, despite of having lost lots of customers to Red Hat's hands.

Also, it was hard to get money from companies, and almost everything seems to have come from caring individuals: message here

Also, it was hard to get money from companies, and almost everything seems to have come from caring individuals: message here

The money has been raised, the purchase shall soon be made. The link is here and you will note that the only companies that put in any money are smaller ones and the rest of the money has come from individuals.

that Apple equipment was bought by Theo using OpenBSD funds. Apple didn't donate anything, nor have they ever

here's what theo has to say about that exact Apple equipment

Some of us want an OS that can run on 128 simultaneous processors as well as one or four or twelve all with the same kernel. Not a cluster. One big computer.

That's fine. Some people, like say, the NASA guys, want an OS that can run on 512 simultaneous processors as well as one or four, or eigth, or 32, or whatever, they want it stable and all with the same kernel. Not a cluster. One big computer. A really big one.

The current raid array is using 14 U160 drives in a dual raid5
configuration with a couple of hot spares. It is time to build up.
See, the actual cvs machine is just a p3/gig machine. While there are
lots of much faster build machines on the network, there has been no
reason to crank the processor on cvs. It is not cpu bound but
*strictly* IO bound. And the raid configuration has been working very
well to keep that IO load under control, well it has been kind of
working.

We support more architectures, which means more NFS load is being
generated. There are more developers, and that does affect things
because developers working fast do checkouts directly off cvs instead
of via mirrors. As well, the array is full (it is half 18GB drives
and half 36GB drives now due to failures after replacement). All of
them are U160 drives.

Now there appears that the raid backplane is developing some issues,
and at the same time, it is time for the "every three to four years"
replace some parts plan. It's what most IT shops do as well. The
drives are also getting a bit up there in age now. Perhaps that is
why I am starting to lose them more often.

But if we want more oomph, then it is time to go to U320. It is also
time to move towards another raid controller (already have it) which
we hope will have supported raid management soon.

So here goes, OpenBSD is making a request for money. They need hardware to replace part of cvs.openbsd.org (the most important part of the OpenBSD development infrastructure) so if you like OpenBSD [or OpenSSH or OpenNTPd] now would be the time to open your walets up.

Marco Peereboom has been assigned to lead this fundraising drive and has started it off with 250 $ out of his own pocket; with a goal of 12,500 $ USD to pay for this hardware.

You can Paypal slash at peereboom dot us or use the OpenBSD Store to donate, simply comment that the funds are to be used on the CVS server.

FWIW I verified that the uploaded files are in fact correct.

Database Support: The drivers are built on top of native drivers... So they often behave differently on various platforms and are sometimes unavailable (See MS-SQL on linux, and don't tell my about FreeTDS, it has been broken for almost two years)

Backward Compatibility: PHP is famous for breaking large things on minor releases. For example somewhere in the 4.1.x series PHP decided that 0 != null anymore. This caused major headaches around here (as we are mostly a PHP shop). Sure it was in the release notes, but who expects such a major change in a minor release?

PHP is stateless, which is good and bad. It is good in that you don't have to think so hard about race conditions, etc. It is bad because you can't pool objects that are expensive to create (other then the built in database pooling). This makes some things very hard to do in PHP that are trivial in Java. For example, sparking a thread to run in the background and reporting on it's progress as time goes on, then sending an email out when the background process finishes.

For personal web projects I still use PHP. For small web projects I use PHP. For throw away web code I still like PHP. For large projects or those with several developers, these days I prefer Java.

And FUD is FUD.

Linux routes over 1Mpps on a single processor system, and 2.1Mpps on a dual processor.

Linux currently holds all the internet land speed records (ipv4 single stream, ipv4 multi stream, ipv6 single stream, ipv6 multi stream).

AC being Alan Cox, DM being Dave Miller.

Read Alan's opinion here.

Read Dave's opinion here.

There has been discussion of this specific Intel announcement here.

AC being Alan Cox, DM being Dave Miller.

Read Alan's opinion here.

Read Dave's opinion here.

There has been discussion of this specific Intel announcement here.

AC being Alan Cox, DM being Dave Miller.

Read Alan's opinion here.

Read Dave's opinion here.

There has been discussion of this specific Intel announcement here.

Funny, I had the opposite reaction. Considering that he tested optimized Gentoo (I'm assuming it was comiled from source for i686)

This would make a few % difference, if you're lucky.

w/ ReiserFS (isn't it still considered non-standard in Linux?) against binary installations (i.e. compiled for i486) of FreeBSD 4 & 5, I would say that FreeBSD delivered a very strong performance.

No ReiserFS is probably the first shipping journalling filesystem for Linux. SUSE has used it in SLES for many years.

Regarding 4 vs. 5: if you consider that many code paths in FreeBSD 5 are considerably more expensive than in 4 due to the fine-grained mutexing, it's impressive that the first truly useable release of 5.x is already keeping up (for the most part) with the simpler, highly uni-processor optimized FreeBSD 4. It was also impressive that KSE delivered roughly the same performance as LinuxThreads, again considering the small amount of time that KSE has been in widespread use.

Not when you consider than Linux 2.6 is far and away more scalable than FreeBSD 5, while also having much better single threaded performance than FreeBSD 4.

If you read the FreeBSD developer lists even a little bit, you would find that the focus of work so far has been on laying the foundation for fine-grained SMP and threading to eliminate the scalability cap of FreeBSD 4's fully locked (i.e. non-SMP) kernel. It will take some time before the fruits of that labor result in significantly higher performance (especially in the uni- and dual-processor cases). In some areas (e.g. packet throughput), FreeBSD 5 already trounces FreeBSD 4 and Linux 2.6. In others, the shorter code paths and years of optimization in FreeBSD 4 still can't be beat. This seems quite reasonable to me.

Actually no, this is forwarding performance that you are thinking of. Linux is much faster in end to end packet processing than FreeBSD, but apparently FreeBSD 5 was supposed to be quicker than Linux when doing forwarding.

But I think their tests were flawed - they claimed they did 1Mpps while Linux couldn't do much over 100Kpps, although I have seen many reports of Linux doing 4-600 on similar hardware.

Also - some tweaking to their driver shows performance can be improved past what FreeBSD can do - 1.1Mpps with a *single* Opteron (rather than dual Xeons), and 2.1Mpps with dual Opterons.
link

1.)

This is a copout. Linux exposes a POSIX API to userspace, and that's what it runs. If FreeBSD can't provide POSIX API services any faster, then it is slower.

2.) It was local. And the same benchmark is being run on each OS, so there is no need to isolate it.

3.) Dude, you had earlier been bashing the Gentoo results for compiling the system with different options, and also thinking things weren't consistent enough.

Also, like super smack, MySQL is primarily developed on Linux, so it's to be expected that it would perform best on that platform especially without compiler optimizations or platform-specific patches.

If there is a patch that improves performance on some OS, it will be included in MySQL if it isn't a cludge to work around some horrible performance limitation.

Most of my criticisms could also be applied in defense of the other OS's.

No they couldn't.

In conclusion, while these benchmarks are mildly interesting and I think the author attempted to achieve unbiased results, the methodology is primitive, cursory, and leaves muliple significant factors unaddressed. Forming an opinion based on these benchmarks is really not possible due to all the shortcomings and unknown variables.

What would you have him test? Some imaginary database that is developed on FreeBSD and which runs fastest on FreeBSD? OK. Meanwhile, the rest of us will try to get some useful work done.

If it can't stay stable on x86, the other ports can only be worse by extrapolation. I've never heard (personally) of Linux 2.6 running on SGI MIPS machines, and in Gentoo Portage it's impossible to emerge a mainline kernel on MIPS without hacking about.

I have heard of SGI MIPS machines running on Linux 2.6. I don't know about gentoo though.

So where's your evidence? You have some of mine, and that was what I could get off the top of my head.

Your "evidence", apart from not being a credible link, is anecdotal and doesn't really prove anything. I can do that too, watch this:

NetBSD 2.0 has memory leaks, is broken on SMP, annd has broken locking.

And that was just what I could get off the top of my head.

If it can't stay stable on x86, the other ports can only be worse by extrapolation. I've never heard (personally) of Linux 2.6 running on SGI MIPS machines, and in Gentoo Portage it's impossible to emerge a mainline kernel on MIPS without hacking about.

I have heard of SGI MIPS machines running on Linux 2.6. I don't know about gentoo though.

So where's your evidence? You have some of mine, and that was what I could get off the top of my head.

Your "evidence", apart from not being a credible link, is anecdotal and doesn't really prove anything. I can do that too, watch this:

NetBSD 2.0 has memory leaks, is broken on SMP, annd has broken locking.

And that was just what I could get off the top of my head.

If it can't stay stable on x86, the other ports can only be worse by extrapolation. I've never heard (personally) of Linux 2.6 running on SGI MIPS machines, and in Gentoo Portage it's impossible to emerge a mainline kernel on MIPS without hacking about.

I have heard of SGI MIPS machines running on Linux 2.6. I don't know about gentoo though.

So where's your evidence? You have some of mine, and that was what I could get off the top of my head.

Your "evidence", apart from not being a credible link, is anecdotal and doesn't really prove anything. I can do that too, watch this:

NetBSD 2.0 has memory leaks, is broken on SMP, annd has broken locking.

And that was just what I could get off the top of my head.

>>b) linux performance in LAMP applications is
>>generally accepted to be better now, sorry but
>>it's true. Unless you take your statement to
>>mean that performance AND tranquility in which
>>case it's just a preference either way.
>
>Keep dreaming, FreeBSD beats the pants off Linux
>(1Mpps vs. 100kpps). And if you were not a Linux

In case you didn't know, they supposedly reached 1Mpps _forwarding_ in a highly specialised environment. The most significant thing was that fast forwarding was turned on, which basically takes the operating system out of the equation and does NIC-NIC forwarding on the bus. Of course, this breaks down if you want to do much useful with the packets.

But what's even funnier is that the FreeBSD guys have no idea what Linux can do. This guy is routing 2.1Mpps on a dual opteron with 4 NICs, 2 bound to each CPU. This shows that he could do over 1Mpps on a single opteron CPU with 2 NICs - more impressive than the FreeBSD result of 1Mpps with DUAL Xeons.

>user you would see the poem was a counter-troll
>to a troll about BSD dying. Linux has its merits,
>but BSD is my favorite for many reasons and as
>long as you Linux folk keep badmouthing BSD you
>will get a very bitter taste of your own medicine
>because it's based on undeniable facts. Read it
>and go weep with Tux, he could use some company

And what's funnier again, is that the routing performance document you cited is a *very* specialised workload that not a lot of people will use FreeBSD (or Linux) i386 PCs for.

The OP was talking about LAMP performance, which is to say, a typical database driven webserver. In which case, you might find this enlightening.

Later in that same thread: http://marc.theaimsgroup.com/?l=netbsd-tech-kern&m =110618215623555&w=2

Should be more careful about what you post. Doesn't help your credibility, Anonymous Coward.

NetBSD? Are you serious?

They've got these deadlocks in the TLB IPI shootdown code that nobody can seem to fix even though they're running a single big kernel lock.

They don't have basic high performance networking features like SACK.

Their IO subsystem is buggy and slow

Their threading system has fundamental flaws

I could go on. Why aren't you BSD zealots just content to leave Linux out of it. This is a BSD story, and yet you always feel the need to snipe at Linux. Must be small dick syndrome.

NetBSD? Are you serious?

They've got these deadlocks in the TLB IPI shootdown code that nobody can seem to fix even though they're running a single big kernel lock.

They don't have basic high performance networking features like SACK.

Their IO subsystem is buggy and slow

Their threading system has fundamental flaws

I could go on. Why aren't you BSD zealots just content to leave Linux out of it. This is a BSD story, and yet you always feel the need to snipe at Linux. Must be small dick syndrome.

NetBSD? Are you serious?

They've got these deadlocks in the TLB IPI shootdown code that nobody can seem to fix even though they're running a single big kernel lock.

They don't have basic high performance networking features like SACK.

Their IO subsystem is buggy and slow

Their threading system has fundamental flaws

I could go on. Why aren't you BSD zealots just content to leave Linux out of it. This is a BSD story, and yet you always feel the need to snipe at Linux. Must be small dick syndrome.

NetBSD? Are you serious?

They've got these deadlocks in the TLB IPI shootdown code that nobody can seem to fix even though they're running a single big kernel lock.

They don't have basic high performance networking features like SACK.

Their IO subsystem is buggy and slow

Their threading system has fundamental flaws

I could go on. Why aren't you BSD zealots just content to leave Linux out of it. This is a BSD story, and yet you always feel the need to snipe at Linux. Must be small dick syndrome.

NetBSD? Are you serious?

They've got these deadlocks in the TLB IPI shootdown code that nobody can seem to fix even though they're running a single big kernel lock.

They don't have basic high performance networking features like SACK.

Their IO subsystem is buggy and slow

Their threading system has fundamental flaws

I could go on. Why aren't you BSD zealots just content to leave Linux out of it. This is a BSD story, and yet you always feel the need to snipe at Linux. Must be small dick syndrome.

And no, Linux has never had a full package tree, because LINUX IS NOT AN OPERATING SYSTEM. It's a kernel. DISTRIBUTIONS have package trees, but they don't release at the same time new kernel versions do, so being able to install a distro from the latest kernel isn't always possible until the next release; this becomes important when your installation requires new drivers only found in the latest kernel.

If you don't know what you're doing, you shouldn't be doing it, right?

FreeBSD's SMP is not substandard,

Yes it is, considering that was the primary focus of the FreeBSD5 development branch, and its taken them 5 years to get here.

by all rights it's one of the better free ones,

No it isn't. I've seen posts within the last 6 months of people not being able to scale database workloads to 2 Opteron CPUs. That's right, their 2 and 4 processor results were the same or worse than their single processor results. Linux scaled linearly, naturally.

And don't tell me "oh they just fixed that". We're talking about 5 years to get it right.

Show me a benchmark comparing FreeBSD with Windows, Linux, Solaris, AIX, IRIX, or anything else with decent SMP support. Only then will I believe you.

its entire code base just needs a LOT more work before it's 'there'. And I doubt you'll find a definitive SMP 'standard' there too. What, Linux is the standard for everything? Looks like all the BSDs have super-standard security, quality assurance, release engineering, consistency, documentation and developer support. I'll also remind people that eth1394 (Linux ip-over-firewire driver) is less than half as fast as FreeBSD's fwe and fwip, and has not improved in this regard since 2.4 days. Hardly anyone even notices; but benchmark it on your home machines and just TRY to get netperf to report more than 116Mb/s throughput.

Stop your blathering and trolling. What the fuck "may I remind people that [blah blah is better in FreeBSD", WTF is that? May I remind you that you're a troll and have provided exactly zero evidence for any of your wild claims?

Hardly anyone notices probably because nobody using Linux cares about IP over firewire.

You keep using it though, I guess you might say it makes up for the lack of 10GbE, Infiniband, USB2 (that actually works), PCI express, etc support. Or not.

Hey, may I remind you that FreeBSD 5's IO subsystem performance is pathetic compared to Linux? This time with actual facts.

Hey bozo, NetBSD isn't the be all and end all that you would like to have us think.

There are plenty of areas where NetBSD is behind Linux in portability and hardware support and performance. Like this simple test where Linux quadruples its performance.

X11 is already working with wsfb.
See here and here.

X11 is already working with wsfb.
See here and here.

> Let me begin by giving you a timeline:
>
> December 15th: I send Linus a mail with a subject line of
> "RLIMIT_MEMLOCK bypass with locked stack"
> December 27th: The PaX team sends Linus a mail with a subject line of
> "2.6.9+ mlockall/expand_down DoS by unprivileged users"
> January 2nd: The PaX team resends the previous mail to Linux and Andrew
> Morton
>
> Between December 15th and today, Linus has committed many changes to
> the kernel. Between January 2nd and today, Andrew Morton has committed
> several changes to the kernel. 3 weeks is a sufficient amount of time
> to be able to expect even a reply about a given vulnerability. A patch
> for the vulnerability was attached to the mails, and in the PaX team's
> mails, a working exploit as well. Private notification of
> vulnerabilities is a privilege, and when that privilege is abused by not
> responding promptly, it deserves to be revoked.

An unprivileged local user can DoS a Linux box to death with malloc and
memset, so the RLIMIT_MEMLOCK bug isn't particularly exceptional. All the
others require root anyway.

I'll pass this on to appropriate people, see if we can get this all fixed
up, thanks.

You can find the reply given by Andrew Morton here. This silence had a reason.

Blatant troll, besides which the vunerability is already fixed.

raw diffs to for those brave souls who want them

While we are on the subject, OpenBSD is also looking for donations (around $20,000) to organize their anual hackathon, a one week meeting of most OpenBSD developers.

See Theo's mails to misc@: (1) and (2)

While we are on the subject, OpenBSD is also looking for donations (around $20,000) to organize their anual hackathon, a one week meeting of most OpenBSD developers.

See Theo's mails to misc@: (1) and (2)

I have a FAQ about this exact thing for this exact reason on my website.

The PHP Manual says not to use PHP and Apache2 in production. This is because of multi-threading issues. Some PHP libraries are not thread-safe and therefore can crash PHP. These errors are often not seen by smaller or low-traffic sites as they are due to race conditions in the libraries. If you want to use Apache2 with PHP and not have it crash, the recommendation is to use Apache2's prefork mode.

See this thread on the php-general list for more discussion.

... facts are facts ;)

FreeBSD 5.3 20 times slower than Linux in real world threaded workload

Looks like you didn't read the Bugtraq posting completely... There's an zip attachment with the fully decoded perl script.
Download link

Read the thread, here

S