I don't recall Clinton ever proposing that we invade Iraq (why?).
Here is to refresh your fading memory. In particular, by Clinton himself (emphasis mine):
"One way or another, we are determined to deny Iraq the capacity to
develop WMD and the missiles to deliver them."
-- BILL CLINTON FEB 4, 1998
"If Saddam rejects peace and we have to use force, our purpose is
clear. We want to seriously diminish the threat posed my Iraq's WMD
program."
-- BILL CLINTON FEB 17, 1998
There is more by Senator Clinton, Vice-President Al Gore, Madeline Albright (and other Clinton administration officials), Senator Kerry, Representative Pelosi, others. Quite a war-mongering bunch...
Of course not: your indulgence in "extreme exaggeration", attacking the messenger rather than addressing the inconvenient facts
Let me remind you, what "fact", we are talking about. That neocons organized 9/11 to advance their agenda. Sorry, until solid evidence comes up, this will not become an established fact. The only thing supporting this allegation is "mere rhetoric" itself (as in: "coincidence? I don't think so!"), and is best ignored or ridiculed, or, when one feels like it, confronted with other "mere rhetoric"...
but chronic hunger is "absolute" poverty, even in America
First of all, thank you for confirming, there is no decline (rapid or otherwise), contrary to your erroneous earlier suggestion. I don't think, there is much hatred, lies, or war either (especially, what can be blamed on your favorite president), but let's now dispense with the poverty.
In my 12 years here I'm yet to see a chronically hungry person. Although during the first year here we did use the foodstamps and free food handouts (and thus were counted by the people in your link), and were certainly poor by American standards, by those of most of the world we were quite rich.
In fact, the ability to go once a week and pick up as much free food as we needed was eerily similar to the Communist utopia, that USSR kept promising its citizens for decades.
With my background thus revealed, let me re-state for the record, that an able bodied person born and raised in America has no one but him/herself to blame for being unable to afford something he/she wants. And the existing safety nets keep the failures well above the absolute poverty -- I know, I had to use it.
but there is also unavoidable poverty, largely through miseducation of children like these
There is. But even that is only relative poverty. The poorest and most miseducated still have clothing, shelter, food and/or opportunity to get them (through charity or honest labor) which makes countless millions of the truly poor world-wide jealous.
Maybe, you just need to travel some? Here is a fact for you. There are many laborers from Myanmar in Thailand (most of them illegal), because the pay is better. There are many Thai laborers in Israel, because the pay is better. And yet there are many Israeli laborers in US, because the pay is even better. "Better" (and "poor") are relative, and America -- with some of the rich European countries -- are on the top of the chain.
This is not a reason for compassionate people to stop caring for the unfortunate, but:
they should focus their efforts on the truly poor of the world;
they should not blame others (and the government) for the ills they have nothing to do with.
Rhetoric (which can legitimately include extreme exaggeration) is the way to dispute facts
Oops, forgot to put the "facts" in quotes. The timing of the "Pearl Harbor scale event" is no more significant, than the tsunami's happening on Christmas (and -- just recently -- on Easter).
A few months later, a Pearl Harbor scale event occurs.
Why are you still chewing on 9/11, when a much more recent BushCrime [TM] took place next to Sumatra last December? If that was not a perfect distraction of the BushFailure [TM] in Illegal War for Oil [TM], what will ever be? Only in neocon's book would such a perfectly timed "disaster" be considered a coincidence!
Your kind of zombie is easy to identify: you can't dispute the facts, or the simple logic, so you attack the messenger with rhetoric and extreme exaggeration.
Rhetoric (which can legitimately include extreme exaggeration) is the way to dispute facts. What are you doing here, anyway? It is May 1st, you are supposed to be demonstrating outside...
I hope you're enjoying Bush's America, composed of lies, hatred, war, poverty, and rapid decline.
I'm enjoying it quite a bit, thank you very much. Especially the non-existing poverty (America has no absolute poverty, only the relative kind) and the steady growth.
The initial version started in December 2001. epoll in its present form was added to the base kernel in 2.5.45, October 2002.
December 2001 is 18 months after April 2000 -- which is when kqueue stuff was merged from -current into -stable branches of FreeBSD. "Initial version" was available even earlier, of course.
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.
This may be a flaw in the implementation (or even just the documentation), which would've been different on Linux anyway. Why could not Linux provide a compatible API along with the improvements in the implementation? NIH seems like the reason...
Well, well, the exploit works. You should really test a feature before arguing about it.:)
Would you care to show your code before overexciting the fans? In my tests attempts to read from such mmapings result in SIGBUS -- on FreeBSD-5.4 and on 4.10.
When we designed epoll for Linux 2.5, kqueue was considered as well as the experimental/dev/epoll.
kqueue is in FreeBSD since 4.1 or, at least, April 2000. epoll was first introduced into Linux-2.5.x (when exactly?) and is still not present in production kernels -- you blame Red Hat.
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.
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).
However you slice it, FreeBSD is just superior. In this very thread we found:
mmap:
no requirements for files being readable as well as writable;
no size (nor offset) alignment requirement;
ability to mmap sparse files for writing is found in both OSes -- my wrong.
kqueue:
found in stable FreeBSD releases since 2000, while no equivalent seems available in stable Linux distros in 2005;
whatever equivalent there is in new kernels, it is gratuitously incompatible with other OSes, that "got there first".
zealots/advocates -- last, but not least:
Linux people tried to "prove", the missing features are not possible or represent security holes;
one pro-Linux AC even used a profanity against kqueue...
But that much we knew all along:-) -- my initial post was a call for Linux to fix the shortcomings, I did not mean to rub them into Linux fans like this...
Thanks for the informative reply, but it merely provides a workaround. kqueue offered a solution, but Linux could not just adapt it, it had to grow something else, that is, apparently, still not in the production kernels -- that's my grudge...
Also, last time I checked (about a year ago?) fam was, sadly, not using kqueue on FreeBSD. In fact, fam-2.6.9 on my FreeBSD-5.x box is using almost 10% of dual Xeon 450MHz right now... But that is a problem for fam-port maintainers.
I dunno if you are just kidding, or if you really cannot do this.
Khmm, your diff works (except for the MAP_SHARED/MAP_PRIVATE hunk -- you need to keep the MAP_SHARED or else no output is ever written to disk). The requirements for the size alignment and O_RDWR are odd, but not show-stopping.
I wonder, what the problem was, when I last tried this on Linux... Probably, it was that I tried a non-aligned output size and O_WRONLY and blamed the error on the lack of real backing store (unfairly).
Alright, one down, one more to go. Can epoll be used to make tail -f better, the way kqueue is used on FreeBSD?
epoll's man-page is dated 2002, whereas kqueue exists in FreeBSD since (at least) 2000. I think, it was wrong for Linux to introduce a totally different API to address the same concerns. Our RedHat is running 2.4.20-31.9bigmem and does not have epoll anyway...
But if it did, would one be able to use epoll to make tail -f more efficient? Or is that, whan [id]notify are for?
As for mmap() -- please download my simple program and try to get it to work on Linux.
In your example, you're just filling in a sparse file that's already logically X bytes long.
Yes. And my example works on FreeBSD, but -- for some reason -- not on Linux -- can't even mmap the input, much less grow the output. Which was the whole point of my original post.
Do you see any value in your participation in this thread?
I can't see how writing to the memory and then ftruncating the file works on BSD. There needs to be some backing store for the memory that you write.
Not necessarily. The backing store can be created by the kernel on the fly, once the process tries to write to the mmap-ed, but not backed space.
This is what I do: open, ftruncate up to 2Gb, write, unmap, ftruncate down to the actual size, close. This is very convenient. For example, one can pass two mmap-ed buffers to something like BZ2_bzBuffToBuffCompress and have an entire file compressed without reads, writes, and useless local buffers.
If you're having problems scaling poll/select, you probably need more hardware.
kqueue lets me know, when the file grows. For example, tail(1) on FreeBSD uses it (with -f and -F switches). How would you do that with select/poll?
What the fuck for?
Is this language normal for Linux-related discourse?
And extending a file via mmap() is effectively impossible. If you don't think so, you don't understand what mmap() really does.
Funny, it works on FreeBSD -- once you ftruncate the file beyond its end, you can mmap it and have the storage allocated automatically, when (and if) you write to it...
You will not be able to mmap() the space "created" by ftruncate(). That's my grudge. I don't want the trouble of maintaining my own buffer(s) and write-ing it/them out.
I want to mmap() way beyond the possible size of the result (very possible especially on 64-bit platforms) and just write to that memory. Once I'm done, I'll ftruncate the file to whatever length it ends up being.
On BSD the method works fine. On Linux it does not:-(
On Solaris (8 and 9 -- not sure about 10) mmap() is even worse, though -- you can only mmap() certain sizes...
Most spam engines don't use a mail queue, which is why
greylisting works so well.
I was talking about a misconfigured server used by spammers because of ignorance (or complacency) of the owners. A growing queue is likely to make them notice the problem.
As for spamd's greylisting, yes, it is another way to implement it. It has an inconvenience, IMHO, requiring a database, whereas my skem keeps the state in a way, that's easy to monitor and alter without special utilities -- relying on the filesystem for efficiency.
You did not really look into it before rushing to "plug" your favorite operating system here, did you?
Try my milter -- it should build on OpenBSD without a problem...
Instead of rejecting e-mails based on RBLs, how about temporarily rejecting them (with a 4xx code)?
This way the accidentally blacklisted server has several days to straighten things out while the really spammy server gets overloaded with huge mail queue.
Using my skem milter is one way to do that intelligently...:-)
You know, in Windows, you can hit Ctl+Alt+Del to bring up the task manager, go to the processes tab, right click on a process, and go to "Set Affinity".
On SunOS it is called pbind and it existed since well before Windows supported SMP at all.
What's to stop them from getting the ship's registry done in Indonesia? Or China for that matter.
Exactly -- nothing. Do you boycot regular Indonesian or Chinese businesses because they may be running sweatshops? If you do -- worry and boycot SeaCode.
Slashdot Mirror
There is more by Senator Clinton, Vice-President Al Gore, Madeline Albright (and other Clinton administration officials), Senator Kerry, Representative Pelosi, others. Quite a war-mongering bunch...
In my 12 years here I'm yet to see a chronically hungry person. Although during the first year here we did use the foodstamps and free food handouts (and thus were counted by the people in your link), and were certainly poor by American standards, by those of most of the world we were quite rich.
In fact, the ability to go once a week and pick up as much free food as we needed was eerily similar to the Communist utopia, that USSR kept promising its citizens for decades.
With my background thus revealed, let me re-state for the record, that an able bodied person born and raised in America has no one but him/herself to blame for being unable to afford something he/she wants. And the existing safety nets keep the failures well above the absolute poverty -- I know, I had to use it.
There is. But even that is only relative poverty. The poorest and most miseducated still have clothing, shelter, food and/or opportunity to get them (through charity or honest labor) which makes countless millions of the truly poor world-wide jealous.Maybe, you just need to travel some? Here is a fact for you. There are many laborers from Myanmar in Thailand (most of them illegal), because the pay is better. There are many Thai laborers in Israel, because the pay is better. And yet there are many Israeli laborers in US, because the pay is even better. "Better" (and "poor") are relative, and America -- with some of the rich European countries -- are on the top of the chain.
This is not a reason for compassionate people to stop caring for the unfortunate, but:
And this timing is the only "fact" presented...
See my other recent posts in this thread for details.
However you slice it, FreeBSD is just superior. In this very thread we found:
mmap: no requirements for files being readable as well as writable; no size (nor offset) alignment requirement; ability to mmap sparse files for writing is found in both OSes -- my wrong. kqueue: found in stable FreeBSD releases since 2000, while no equivalent seems available in stable Linux distros in 2005; whatever equivalent there is in new kernels, it is gratuitously incompatible with other OSes, that "got there first". zealots/advocates -- last, but not least: Linux people tried to "prove", the missing features are not possible or represent security holes; one pro-Linux AC even used a profanity against kqueue...But that much we knew all along :-) -- my initial post was a call for Linux to fix the shortcomings, I did not mean to rub them into Linux fans like this...
Also, last time I checked (about a year ago?) fam was, sadly, not using kqueue on FreeBSD. In fact, fam-2.6.9 on my FreeBSD-5.x box is using almost 10% of dual Xeon 450MHz right now... But that is a problem for fam-port maintainers.
Khmm, your diff works (except for the MAP_SHARED/MAP_PRIVATE hunk -- you need to keep the MAP_SHARED or else no output is ever written to disk). The requirements for the size alignment and O_RDWR are odd, but not show-stopping.
I wonder, what the problem was, when I last tried this on Linux... Probably, it was that I tried a non-aligned output size and O_WRONLY and blamed the error on the lack of real backing store (unfairly).
Alright, one down, one more to go. Can epoll be used to make tail -f better, the way kqueue is used on FreeBSD?
But if it did, would one be able to use epoll to make tail -f more efficient? Or is that, whan [id]notify are for?
As for mmap() -- please download my simple program and try to get it to work on Linux.
Anyway, try to get my little program to work on Linux (without local buffers) and send me the diff...
Do you see any value in your participation in this thread?
Here, try this little program. Compile and link with -lbz2...
This is what I do: open, ftruncate up to 2Gb, write, unmap, ftruncate down to the actual size, close. This is very convenient. For example, one can pass two mmap-ed buffers to something like BZ2_bzBuffToBuffCompress and have an entire file compressed without reads, writes, and useless local buffers.
Don't post anonymously if you want a reply.
I want to mmap() way beyond the possible size of the result (very possible especially on 64-bit platforms) and just write to that memory. Once I'm done, I'll ftruncate the file to whatever length it ends up being.
On BSD the method works fine. On Linux it does not :-(
On Solaris (8 and 9 -- not sure about 10) mmap() is even worse, though -- you can only mmap() certain sizes...
Also, how about growing files with mmap? Currently one can not mmap() beyond the end of the file on Linux...
As for spamd's greylisting, yes, it is another way to implement it. It has an inconvenience, IMHO, requiring a database, whereas my skem keeps the state in a way, that's easy to monitor and alter without special utilities -- relying on the filesystem for efficiency.
You did not really look into it before rushing to "plug" your favorite operating system here, did you?
Try my milter -- it should build on OpenBSD without a problem...
His galaxy is "far away", but the universe may well be ours -- the one and only...
This way the accidentally blacklisted server has several days to straighten things out while the really spammy server gets overloaded with huge mail queue.
Using my skem milter is one way to do that intelligently... :-)