Yes, it is money -- and the hope to be able to earn and spend it in America some day
Bwahahahaha...
The best scenario possible for life is "earn where labour is expensive" and "spend where cost of life is cheap". America does not qualify for either. You can get higher technical salaries in many European countries and the life is considerably more expensive than in plenty of countries around the world with better climate, reasonable infrastructure and most amenities you need to spend the money
I am not saying that some of the people striving for an outsourced buck in China, India, etc do not want to live in America. In fact may of them do. The American movie industry has seen to that.
Funnily enough their number is decreasing very fast. 10 years ago 90%+ of my friends in IT in Eastern Europe were considering emigrating (mostly to EU, not US) as the only option. Nowdays the number is in the sub-10%. After all, getting payed American or British money and spending it in a country where the average salary is 10 times less than what you earn is much more fun than getting a H1B pittance and spending it in a country where the average salary is fairly close to what you earn.
Unless I am mistaken, this is not retorical, it is a clear statement that piracy is being used to fund terrorism.
Frankly, someone in the US gov is taking lessons from the el presidente Antonio Bliar's book that any lie is OK provided that it is for the "just cause". Can we see some damn proof of at least one instance when this has happened?
There will be plenty of growth in Europe in the future as well. In fact plenty of people who have had enough of the "Never say NO to the big white Bwanah" culture prevalent in some parts of Asia have already started moving their businesses to Eastern and Southern Europe. In addition to that you have a number of developed countries with large IT markets which are not going away anytime soon.
Once upon a time my grandgranddad told this to a southerner. The southerner answered with a thick southern accent: "Who is not with us is against us" and continued about "We the good peace loving folks of ***..." (country omitted for sake of argument). 3 years later my grandgrandmom received a letter that grandgranddad was executed as an enemy of the state (in fact he was shot one more year later).
Any similarities with a current southerner whose favourite saying is also "Who is not with us is against us" are mere coincidence I guess...
The same motherboard worked fine with 2.6.8, 2.6.9, 2.6.10 to the extent 2.6.10 VM can be called working, 2.6.11, 2.6.14). No hangs on any one of them. The config is OK as well. Hardware is not at fault either because the hang is 100% reproducible on 2-3 different Via M-I series motherboards with an Eden core. Frankly, I had enough of it so I'd rather port back the patches which I need from 2.6.16 (NFSv4 and ACM), but the underlying tty and locking layers have changed so much that I have to spend more than a week on rewriting the patches and doing the regression testing. IANKD and I do not have that week.
100% guaranteed reproducible on any Via C3V1 with a PREEMPT kernel. I have swapped hardware around multiple times to the same effect. 686 clones including C3V2 do not seem to suffer from it so I suspect something gets badly optimised somewhere for non-SSE capable systems. Dunno what. Got enough other stuff on my plate to spend time on debugging this as well.
More likely he had some really bad acid the previous night.
After all he did more than 6 revisions of the Linux VM using CopyOnWrite before this latest fad.
Possibly more.
Off the top of my head that is at least 1 in the 1.2 tree, 1 in the 2.0 tree, 1 in the 2.2 tree, 2 in the 2.4 tree and more than 2 in the 2.6 tree, all of which being CopyOnWrite and at least some of which has been hailed as the next best thing after hot bread.
As far as the technical point he is possibly correct for x86 where COW goes through the fault mechanism and causes some TLB and cache abuse which is really bad on modern CPUs. I am not sure as far as other architectures are concerned, because IIRC (I may be wrong) the memory mapper hardware on the old Sparc was designed for COW in first place.
Anyway, before calling somebody else an idiot for something you have happily done for 10+ years till yesterday it may be nice if you look at yourself in the mirror. Because I never remember any branch of FreeBSD reaching the point where you can do a find/usr -exec cat {} >/dev/null \; to hang the system. That is 2.6.16 at your service (from rc4 onward) on at least two x86 subarchitectures where I had the time to test it. That is besides the unkillable processes in [S] state on an nfs flock in 2.6.14 (yep, that is a gem which no other unix has managed so far), besides the OOM idiocies in 2.6.10, besides deliberately making it absolutely impossible to backtrack any more interesting patch to a previous kernel without employing a team of kernel developers because the VM and locking is not compatible across any kernel version since 2.6.9 and even when it is something else is changed like the tty layer, besides.... Aarghh.....
Yes, I've had to take one for every single job I've ever held. They were called interviews.
While this attitude is generally correct, most outfits that put too much emphasis on this and too little on actual skill usually tend to slide into the quagmire of mediocrity.
There has to be a balance. Most brilliant people tend to have personality quirks and most people with "perfect fit personalities" tend to be mediocre.
The latter has been proven countless times by various psychological experiments.
We subconciously tend to like the "golden middle".
The following is an experiment which has been done many times with different sample sizes and test groups to the same effect. You give a test group of people some pictures of subjects where all but one have some characteristic visual trait like big nose or big ears or bushy brows. The one exemption is a morph where the bushy brows of subject A are diluted and toned down by the normal brows of all the rest. Similar for the sticking nose of subject B, pointy ears of subject C, etc. In nearly all cases the test group will point to the artificial "average" person as the most trusty looking and most attractive.
Setting a similar experiment with personalities is difficult because the deviations are much harder to quantify. Personally I have not seen publications regarding such experiments, but I am not a psychologist so there may be some. Still, I am pretty sure that if someone manages to formulate a statistically representative setup, the mediocre average personality is usually selected as "this will fit best" and "this is most attractive". Same as with the face morph.
One of the main differences between Debian and RedHat is the level of documentation. Debian is the second best documented Unix system after FreeBSD. RedHat does not even come close. Granted, it has gotten better with ES4/WS4 but it still has a long way to go.
Debian policy specifies that every executable, every config file has to have a man page. Even if the manpage says "look elsewhere" this is still better than the scarce and sporadic upstream manpages you get with RedHat. In addition to that 99%+ of packages that requires configuration by hand (like mailman) has some examples in the/usr/share/doc/package-name directory. Once again, RedHat is pretty scarce on this point.
You are correct that debian is "hard". It is. For people who do not want to read. If you do not mind reading it is a much better starting point for a newbee than RedHat. While I have not played with Ubuntu I suspect that it has inherited this from it.
As far as RTF* is concerned I think the major problem is the overall cultural difference. As noted in one of the old essays by Eric S. Raymond the Unix (and Linux) culture is the culture of verbal and written expression. It is not a good place for people who do not like reading (and writing for that matter). The Windows culture is a culture of visual expression. In order top perform an action it has to be visible. An object ot text must be selectible, its color has to visually change, etc for the action to commence.
As a result of these cultural differences, a person which is incapable of accepting a RTFM answer will not convert to Unix (at least long term). He/she does not fit the culture. Similarly, a person accustomed to verbal/written expression will never be at home with Windows once he/she has seen an alternative. In either case there is no point to try to force the issue.
I have hat to support both categories over the years and I have learned that forcing the issue never helps. Different people have different mindsets and forcing a person to adopt a way of working which contradicts their mindset is always a bad idea.
People complain that RTFM is a snobbish answer. Well, for that matter, "click with right button, select properties, select Advanced, change..." seems even more snobbish for a person who is accustomed to a verbal expression. It is a matter of culture, get over it. People who cannot get over a polite RTFM (with a pointer where to start) do not belong in Unix land. People who cannot get over a 3-4 right button clicks sequence do not belong in Windows land.
It is time to burry the hatchet and not try to force either one of these castes to pray on the others altars. It does not work.
It is a posterchild for how software (free or commercial) MUST be developed. A spec is written first and the software is written to comply to it. The spec doubles up as documentation and is available online with a reasonable glossary and index.
As far as mailman on Debian is concerned a person who has RTFM-ed should have encountered the cut-n-paste example in the/usr/share/doc/mailman which is sufficient to get an install running. If for whatever reason this one has been skipped the same blurb is available in the Mailman FAQ.
If you google for "Exim Mailman" you will hit it nearly immediately.
I had very similar experience when working on 64bit Linux 6 years ago in the days of Debian on alpha. I ended up lifting many libraries out of the NetBSD tree and rebuilding them for Debian because they were the only project at the time which was meticulously cleaned up to be both endian-clean and int-size-clean.
After getting some things working I could not get the packages and patches back because people could not verify them.
As one philosopher once upon a time said: "The language forms the thought". As long as you think in SQL you will be stuck in a 25 year old mentality regardless of the underlying engine. SQL as such is a language which is mostly synchronous. In fact most DBA pray to the god of synchronicity calling it the Holy ACID.
Well, do they like it or not 95%+ of modern applications which feed a DB are network based. Nearly all are asynchronous. Forcing synchronous execution on them kills the performance outright and this is what you get if you try to express their data flows solely in SQL terms.
The alternative is to split the schema into small subschemas each with its own ACID-ity, foreign keys and constraints and link them asynchronously at application level.
One problem though - in order to do this you need to stop thinking and expressing yourself solely in SQL. You need to invoke an additional abstraction layer and use an alternative language to express any asynchronous events and links. SQL limits your mental process so it should be used carefully only for what it is good at - scoping, isolation levels, locking, access granularity, synchronous data changes, transactions and general data access. For everything else use something else. Even perl is better.
I hate to say this but this is never going to happen.
It is a founding principle of American judiciary and politics that "the only law that applies is American". The US position on the
World Criminal Court and the extraction of the dickhead who murdered 20+ civilians in Italy so that he does not go to trial in Italy for this one are just two examples off the top of my head. Plenty of others.
This costs nearly as much as the whole bloody tablet...
The biggest problem with the Nokia is that it has only a USB Device interface. A USB Host interface would have solved most of the usability problems. It would have also allowed it to be used for many applications where people grudgingly accept the exorbitantly priced Tosh or HP tablets. Recently, I was looking for a device to run some fairly trivial software written in Perl or Python to process field lab data. The Nokia would have been the perfect match if it had reasonable means of interfacing. Unfortunately it did not.
You are correct, the browser wars are business as usual as far as corporation behaviour is concerned.
At the same time they are unique as far as quantity of data available on them. They are the first big antitrust case after email became normal means of communication. As such they are the only antitrust case where the students can study how to do the business as usual while not getting caught redhanded.
Personally I disagree with Harvard's intent to industrialise the production of sociopaths who learn how to do the business as usual while not getting caught redhanded in business school. Unfortunately if they do not do it, somebody else will.
IIRC Russians had a similar system ready for the launch of IL86 in the 80-es and abandoned it later for exactly the same reasons. Too much airframe stress.
Nothing sexy in the picture for anyone but necrophiliacs.
On top of this, if you disregard the hole in the forehead, it is also quite tame from the ad/sex/sells/violence perspective. Just compare it to Dress To Kill ads from the Wallis campaign of the mid-90es. That is before even thinking of the Kronenburg advert that got banned by the ASA. That is also before even looking at the kind of ads perfumes are putting for EU market only (Opium with the Naked Sophie Dahl ad being just one example)). They selfcensor themselves and do not print them in American magazines so that they do not have to deal with the Bible Belt dwellers and other Evangelical Talebans.
In fact they do not need a higher value MX at all having all those lower level ones. In fact I will bet a case of beer that it is there to detect zombies. Anything hitting it before touching the lower ones will be presumed zombie and put on "long probation".
My fault. Numbers quoted are for TCP encaps tested over an uncongested 100MB link. UDP goes higher several times. Possibly in the 10s of MBit so 40Mbit you have seen is achievable. Hardware in my deployments has been P4 on one side and Via with hardware AES acceleration on the other. P4 on the other makes no difference. Dropping to Via on both sides also makes no difference.
As far as the CPU it is not the limitation by any means. At least with TCP the client gets to its max throughput long before the CPU has choked on the cipher. I have tried throwing beafy hardware at it with minimal effect. It also very much depends on your kernel options. Turning preemption on, raising HZ, etc raises performance. Leaving at normal server settings drops it.
Overall, it will always be lower than IPSEC which does all of the processing in kernel space and does not have to do two copies between userspace and kernel space for nothing. Its advantages are elsewhere. You can actually build infrastructure with it.
Nope. Whoever wrote it is a dolt (though it is on the OpenVPN pages).
ESP per its RFC definition is a protocol in its own right. It is not over UDP.
Granted, OpenVPN UDP frame format closely resembles the payload part of ESP in uncompressed mode (no point to reinvent the wheel). IIRC the source correctly, once you start using compression the format differs from for both compressed and uncompressed frames (lzo versus deflate compression). In addition to that keying and keepalive are inband on the same UDP connection. This completely kills any resemblance of ESP because every 30 seconds (or whatever you set your ping to) you have a frame which is not present in the ESP RFC definition.
Under IPSEC I mean any standards compliant implementation floating around. I am speaking based on some experience with Checkpoint, Cisco, Nortel, KAME, FreeSwan and a few others. When used in tunnel mode they all suck by design because they do not offer an interface notion to the OS so there is no way to run a routing protocol on the tunnel. They similarly suck QoS-wise. I am using IPSEC because the suckiness is actually a natural result of the RFC definitions of the protocol.
If you use transport mode IPSEC to protect a suitable tunnel protocol like IP in IP you are OK. Unfortunately, this is not an IPSEC use which is common and well supported by most security vendors. Most have serious performance problems when running in this mode.
As far as OpenVPN you are deeply mistaken. It has nothing to do with IPSEC. It uses TLS over TCP or TLS over UDP. The second case requires some sequencing. None of the packet formats has anything to do with the IPSEC RFCs, the OS level abstractions have nothing to do with the RFCs and the keying is not anywhere near the madness specified in the IKE RFC.
If I was them I would have also tracked the connections and tagged as a potential SPAM Zombie anyone who deviates from the expected MX fallback pattern. For example someone who hits MX with a value of 5 without trying any of the 1s is an immediate Zombie candidate. Someone who skips from 1 to 5 directly without going along to the other 1s is an obvious Zombie candidate. Someone who hits more than 1 but not all IPs from one MX in sequence before going to the next MX is also likely to be Zombie because that is not a normal pattern. So on so fourth.
They already have greylisting so the database hooks to do that are already there in the mail server code and configs. From there on doing all of these checks is one-two pages of perl.
Overall - the article is an example of bad methodology, no knowledge of current AntiSPAM and security practices, and lack of proper review before publishing.
Slashdot Mirror
Bwahahahaha...
The best scenario possible for life is "earn where labour is expensive" and "spend where cost of life is cheap". America does not qualify for either. You can get higher technical salaries in many European countries and the life is considerably more expensive than in plenty of countries around the world with better climate, reasonable infrastructure and most amenities you need to spend the money
I am not saying that some of the people striving for an outsourced buck in China, India, etc do not want to live in America. In fact may of them do. The American movie industry has seen to that.
Funnily enough their number is decreasing very fast. 10 years ago 90%+ of my friends in IT in Eastern Europe were considering emigrating (mostly to EU, not US) as the only option. Nowdays the number is in the sub-10%. After all, getting payed American or British money and spending it in a country where the average salary is 10 times less than what you earn is much more fun than getting a H1B pittance and spending it in a country where the average salary is fairly close to what you earn.
Azul does that, but it is a fully specialized hardware. No idea if you can take their core unit and transplant it into an Opteron socket.
Err...
Unless I am mistaken, this is not retorical, it is a clear statement that piracy is being used to fund terrorism.
Frankly, someone in the US gov is taking lessons from the el presidente Antonio Bliar's book that any lie is OK provided that it is for the "just cause". Can we see some damn proof of at least one instance when this has happened?
Why just Asia?
There will be plenty of growth in Europe in the future as well. In fact plenty of people who have had enough of the "Never say NO to the big white Bwanah" culture prevalent in some parts of Asia have already started moving their businesses to Eastern and Southern Europe. In addition to that you have a number of developed countries with large IT markets which are not going away anytime soon.
Once upon a time my grandgranddad told this to a southerner. The southerner answered with a thick southern accent: "Who is not with us is against us" and continued about "We the good peace loving folks of ***..." (country omitted for sake of argument). 3 years later my grandgrandmom received a letter that grandgranddad was executed as an enemy of the state (in fact he was shot one more year later).
Any similarities with a current southerner whose favourite saying is also "Who is not with us is against us" are mere coincidence I guess...
The same motherboard worked fine with 2.6.8, 2.6.9, 2.6.10 to the extent 2.6.10 VM can be called working, 2.6.11, 2.6.14). No hangs on any one of them. The config is OK as well. Hardware is not at fault either because the hang is 100% reproducible on 2-3 different Via M-I series motherboards with an Eden core. Frankly, I had enough of it so I'd rather port back the patches which I need from 2.6.16 (NFSv4 and ACM), but the underlying tty and locking layers have changed so much that I have to spend more than a week on rewriting the patches and doing the regression testing. IANKD and I do not have that week.
No.
It is a proper jolly good hard hang.
100% guaranteed reproducible on any Via C3V1 with a PREEMPT kernel. I have swapped hardware around multiple times to the same effect. 686 clones including C3V2 do not seem to suffer from it so I suspect something gets badly optimised somewhere for non-SSE capable systems. Dunno what. Got enough other stuff on my plate to spend time on debugging this as well.
More likely he had some really bad acid the previous night.
After all he did more than 6 revisions of the Linux VM using CopyOnWrite before this latest fad.
Possibly more.
Off the top of my head that is at least 1 in the 1.2 tree, 1 in the 2.0 tree, 1 in the 2.2 tree, 2 in the 2.4 tree and more than 2 in the 2.6 tree, all of which being CopyOnWrite and at least some of which has been hailed as the next best thing after hot bread.
As far as the technical point he is possibly correct for x86 where COW goes through the fault mechanism and causes some TLB and cache abuse which is really bad on modern CPUs. I am not sure as far as other architectures are concerned, because IIRC (I may be wrong) the memory mapper hardware on the old Sparc was designed for COW in first place.
Anyway, before calling somebody else an idiot for something you have happily done for 10+ years till yesterday it may be nice if you look at yourself in the mirror. Because I never remember any branch of FreeBSD reaching the point where you can do a find /usr -exec cat {} > /dev/null \; to hang the system. That is 2.6.16 at your service (from rc4 onward) on at least two x86 subarchitectures where I had the time to test it. That is besides the unkillable processes in [S] state on an nfs flock in 2.6.14 (yep, that is a gem which no other unix has managed so far), besides the OOM idiocies in 2.6.10, besides deliberately making it absolutely impossible to backtrack any more interesting patch to a previous kernel without employing a team of kernel developers because the VM and locking is not compatible across any kernel version since 2.6.9 and even when it is something else is changed like the tty layer, besides.... Aarghh.....
While this attitude is generally correct, most outfits that put too much emphasis on this and too little on actual skill usually tend to slide into the quagmire of mediocrity.
There has to be a balance. Most brilliant people tend to have personality quirks and most people with "perfect fit personalities" tend to be mediocre.
The latter has been proven countless times by various psychological experiments.
We subconciously tend to like the "golden middle".
The following is an experiment which has been done many times with different sample sizes and test groups to the same effect. You give a test group of people some pictures of subjects where all but one have some characteristic visual trait like big nose or big ears or bushy brows. The one exemption is a morph where the bushy brows of subject A are diluted and toned down by the normal brows of all the rest. Similar for the sticking nose of subject B, pointy ears of subject C, etc. In nearly all cases the test group will point to the artificial "average" person as the most trusty looking and most attractive.
Setting a similar experiment with personalities is difficult because the deviations are much harder to quantify. Personally I have not seen publications regarding such experiments, but I am not a psychologist so there may be some. Still, I am pretty sure that if someone manages to formulate a statistically representative setup, the mediocre average personality is usually selected as "this will fit best" and "this is most attractive". Same as with the face morph.
One of the main differences between Debian and RedHat is the level of documentation. Debian is the second best documented Unix system after FreeBSD. RedHat does not even come close. Granted, it has gotten better with ES4/WS4 but it still has a long way to go.
Debian policy specifies that every executable, every config file has to have a man page. Even if the manpage says "look elsewhere" this is still better than the scarce and sporadic upstream manpages you get with RedHat. In addition to that 99%+ of packages that requires configuration by hand (like mailman) has some examples in the /usr/share/doc/package-name directory. Once again, RedHat is pretty scarce on this point.
You are correct that debian is "hard". It is. For people who do not want to read. If you do not mind reading it is a much better starting point for a newbee than RedHat. While I have not played with Ubuntu I suspect that it has inherited this from it.
As far as RTF* is concerned I think the major problem is the overall cultural difference. As noted in one of the old essays by Eric S. Raymond the Unix (and Linux) culture is the culture of verbal and written expression. It is not a good place for people who do not like reading (and writing for that matter). The Windows culture is a culture of visual expression. In order top perform an action it has to be visible. An object ot text must be selectible, its color has to visually change, etc for the action to commence.
As a result of these cultural differences, a person which is incapable of accepting a RTFM answer will not convert to Unix (at least long term). He/she does not fit the culture. Similarly, a person accustomed to verbal/written expression will never be at home with Windows once he/she has seen an alternative. In either case there is no point to try to force the issue.
I have hat to support both categories over the years and I have learned that forcing the issue never helps. Different people have different mindsets and forcing a person to adopt a way of working which contradicts their mindset is always a bad idea.
People complain that RTFM is a snobbish answer. Well, for that matter, "click with right button, select properties, select Advanced, change ..." seems even more snobbish for a person who is accustomed to a verbal expression. It is a matter of culture, get over it. People who cannot get over a polite RTFM (with a pointer where to start) do not belong in Unix land. People who cannot get over a 3-4 right button clicks sequence do not belong in Windows land.
It is time to burry the hatchet and not try to force either one of these castes to pray on the others altars. It does not work.
I do not recall myself replying with that though for many years now (I do not hang out on IRC though).
In fact I do not recall myself with a RTFM reply which does not point to a specific FM for many years now (7+ at least).
It is not snobbish and snubbish to tell someone to RTFM. It is snobbish and snubbish to tell someone to RTFM without telling where to RTFM.
Not for Exim.
/usr/share/doc/mailman which is sufficient to get an install running. If for whatever reason this one has been skipped the same blurb is available in the Mailman FAQ.
It is a posterchild for how software (free or commercial) MUST be developed. A spec is written first and the software is written to comply to it. The spec doubles up as documentation and is available online with a reasonable glossary and index.
As far as mailman on Debian is concerned a person who has RTFM-ed should have encountered the cut-n-paste example in the
If you google for "Exim Mailman" you will hit it nearly immediately.
Yep. I will second that.
I had very similar experience when working on 64bit Linux 6 years ago in the days of Debian on alpha. I ended up lifting many libraries out of the NetBSD tree and rebuilding them for Debian because they were the only project at the time which was meticulously cleaned up to be both endian-clean and int-size-clean.
After getting some things working I could not get the packages and patches back because people could not verify them.
As one philosopher once upon a time said: "The language forms the thought". As long as you think in SQL you will be stuck in a 25 year old mentality regardless of the underlying engine. SQL as such is a language which is mostly synchronous. In fact most DBA pray to the god of synchronicity calling it the Holy ACID.
Well, do they like it or not 95%+ of modern applications which feed a DB are network based. Nearly all are asynchronous. Forcing synchronous execution on them kills the performance outright and this is what you get if you try to express their data flows solely in SQL terms.
The alternative is to split the schema into small subschemas each with its own ACID-ity, foreign keys and constraints and link them asynchronously at application level.
One problem though - in order to do this you need to stop thinking and expressing yourself solely in SQL. You need to invoke an additional abstraction layer and use an alternative language to express any asynchronous events and links. SQL limits your mental process so it should be used carefully only for what it is good at - scoping, isolation levels, locking, access granularity, synchronous data changes, transactions and general data access. For everything else use something else. Even perl is better.
It is a founding principle of American judiciary and politics that "the only law that applies is American". The US position on the World Criminal Court and the extraction of the dickhead who murdered 20+ civilians in Italy so that he does not go to trial in Italy for this one are just two examples off the top of my head. Plenty of others.
The biggest problem with the Nokia is that it has only a USB Device interface. A USB Host interface would have solved most of the usability problems. It would have also allowed it to be used for many applications where people grudgingly accept the exorbitantly priced Tosh or HP tablets. Recently, I was looking for a device to run some fairly trivial software written in Perl or Python to process field lab data. The Nokia would have been the perfect match if it had reasonable means of interfacing. Unfortunately it did not.
At the same time they are unique as far as quantity of data available on them. They are the first big antitrust case after email became normal means of communication. As such they are the only antitrust case where the students can study how to do the business as usual while not getting caught redhanded.
Personally I disagree with Harvard's intent to industrialise the production of sociopaths who learn how to do the business as usual while not getting caught redhanded in business school. Unfortunately if they do not do it, somebody else will.
IIRC Russians had a similar system ready for the launch of IL86 in the 80-es and abandoned it later for exactly the same reasons. Too much airframe stress.
Nothing sexy in the picture for anyone but necrophiliacs.
On top of this, if you disregard the hole in the forehead, it is also quite tame from the ad/sex/sells/violence perspective. Just compare it to Dress To Kill ads from the Wallis campaign of the mid-90es. That is before even thinking of the Kronenburg advert that got banned by the ASA. That is also before even looking at the kind of ads perfumes are putting for EU market only (Opium with the Naked Sophie Dahl ad being just one example)). They selfcensor themselves and do not print them in American magazines so that they do not have to deal with the Bible Belt dwellers and other Evangelical Talebans.
Nothing to see here, move along...
Exactly.
In fact they do not need a higher value MX at all having all those lower level ones. In fact I will bet a case of beer that it is there to detect zombies. Anything hitting it before touching the lower ones will be presumed zombie and put on "long probation".
My fault. Numbers quoted are for TCP encaps tested over an uncongested 100MB link. UDP goes higher several times. Possibly in the 10s of MBit so 40Mbit you have seen is achievable. Hardware in my deployments has been P4 on one side and Via with hardware AES acceleration on the other. P4 on the other makes no difference. Dropping to Via on both sides also makes no difference.
As far as the CPU it is not the limitation by any means. At least with TCP the client gets to its max throughput long before the CPU has choked on the cipher. I have tried throwing beafy hardware at it with minimal effect. It also very much depends on your kernel options. Turning preemption on, raising HZ, etc raises performance. Leaving at normal server settings drops it.
Overall, it will always be lower than IPSEC which does all of the processing in kernel space and does not have to do two copies between userspace and kernel space for nothing. Its advantages are elsewhere. You can actually build infrastructure with it.
Nope. Whoever wrote it is a dolt (though it is on the OpenVPN pages).
ESP per its RFC definition is a protocol in its own right. It is not over UDP.
Granted, OpenVPN UDP frame format closely resembles the payload part of ESP in uncompressed mode (no point to reinvent the wheel). IIRC the source correctly, once you start using compression the format differs from for both compressed and uncompressed frames (lzo versus deflate compression). In addition to that keying and keepalive are inband on the same UDP connection. This completely kills any resemblance of ESP because every 30 seconds (or whatever you set your ping to) you have a frame which is not present in the ESP RFC definition.
Coming soon?
4 26234
They are already here: http://yro.slashdot.org/article.pl?sid=06/03/19/1
Under IPSEC I mean any standards compliant implementation floating around. I am speaking based on some experience with Checkpoint, Cisco, Nortel, KAME, FreeSwan and a few others. When used in tunnel mode they all suck by design because they do not offer an interface notion to the OS so there is no way to run a routing protocol on the tunnel. They similarly suck QoS-wise. I am using IPSEC because the suckiness is actually a natural result of the RFC definitions of the protocol.
If you use transport mode IPSEC to protect a suitable tunnel protocol like IP in IP you are OK. Unfortunately, this is not an IPSEC use which is common and well supported by most security vendors. Most have serious performance problems when running in this mode.
As far as OpenVPN you are deeply mistaken. It has nothing to do with IPSEC. It uses TLS over TCP or TLS over UDP. The second case requires some sequencing. None of the packet formats has anything to do with the IPSEC RFCs, the OS level abstractions have nothing to do with the RFCs and the keying is not anywhere near the madness specified in the IKE RFC.
I expect it is not just that.
If I was them I would have also tracked the connections and tagged as a potential SPAM Zombie anyone who deviates from the expected MX fallback pattern. For example someone who hits MX with a value of 5 without trying any of the 1s is an immediate Zombie candidate. Someone who skips from 1 to 5 directly without going along to the other 1s is an obvious Zombie candidate. Someone who hits more than 1 but not all IPs from one MX in sequence before going to the next MX is also likely to be Zombie because that is not a normal pattern. So on so fourth.
They already have greylisting so the database hooks to do that are already there in the mail server code and configs. From there on doing all of these checks is one-two pages of perl.
Overall - the article is an example of bad methodology, no knowledge of current AntiSPAM and security practices, and lack of proper review before publishing.