I'll give 10:1 odds that Futuremark simply compiled their benchmark with Intel's C++ compiler.
I wrote a detailed explanation back in 2005 about how the Intel C++ compiler generates separate code paths for memory operations to make AMD processors appear significantly slower, and how you can trick the compiled code into believing your AMD processor is an Intel one to see incredibly increased performance. See this article for additional details.
I noticed this problem back in January of 2004, with Intel C++ 8.0, and went through heck over nine months with Intel's customer support to get it fixed until I eventually had to abandon their compiler.
On any non-Intel processors, it specifically included an alternate code path for "memcpy" that actually used "rep movsb" to copy one byte at a time, instead of (for example) "rep movsd" to copy a doubleword at a time (or MMX instructions to copy quadwords). This was probably the most brain-dead memcpy I'd ever seen, and was around 4X slower than even a typical naive assembly memcpy:
push ecx shr ecx, 2 rep movsd pop ecx and ecx, 3 rep movsb
They responded with completely ridiculous answers, such as:
"Our 8.0 memcpy was indeed optimized for a Pentium(r)4 Processor,when we reworked this routine we used the simplest, most robust, and straightforward implementation for older processors so that we didn't need the extra code to check for alignment, length, overlap, and other conditions."
BS. I went and added the following line to the beginning of my source code:
extern "C" int __intel_cpu_indicator;
then I added:
__intel_cpu_indicator = -512;
to the "main" function.
This forced Intel C++ to use the "Pentium 4" memcpy regardless of which processor in in the machine. It turns out that their special "Pentium 4" memcpy which I tested thoroughly in all kinds of situations, and it worked perfectly fine on an AMD Athlon and a Pentium III. I pointed this out to them.
I received the following response:
"The fast mempcy is over 2000 lines of hand coded assembly, with lots of special cases where different code paths are chosen based on relative alignment of the source and destination.... If the performance of memcpy/memset only are improved for Pentium III will that satisfy you?"
I answered "No," saying that I needed support for AMD processors as well. I also gave them a copy of my own memcpy routine that was 50% faster than theirs--and just used MMX. They closed the support issue and did nothing to resolve it.
Since it may not be obvious to all readers, be aware that when you can make a program crash by feeding it bad data, you can typically further manipulate the data you are sending it to take control of the program. That means a security hole. This is how buffer-overruns work. You can't always do it, but you can think of each way you can crash a program as a little "crack" in its exterior. If you can figure out a way to pry apart the crack, you've got yourself a hole.
So many of these "bugs" in Mozilla, Opera, Lynx, and Links are likely security holes as well.
It is interesting, then, to see that Internet Explorer did so well on this, with its notoriously bad history on security. My first instinct would be that the HTML parsing engine in Internet Explorer was written by a different team of programmers than worked on the rest of the software, and they used proper programming techniques (such as RAII in C++, or perhaps used one of their.NET languages, rather than programming in straight C like the others) which as a side effect prevented such problems.
Let's hope that all these bugs are taken care of in the other browsers quickly before the black hats find ways to make use of them.
Unfortunately, the article this story links to has a rather large mistake. It states:
However, AIM users would have to click on the URL to trigger the vulnerability, which will make it harder for malicious hackers or virus writers to use it in automated attacks, Weinstein said.
This is completely and totally wrong.
Any web page can launch URLs of the form aim:goaway?message=Anything+goes+here by many different means without user intervention:
Redirect response codes
Meta redirect tags
Frames
iframes
Javascript popups
Any one of those methods will change your away message automatically, without any confirmation on your part. And if the part in the message= section is more than 1024 characters, arbitrary code can be executed on your machine.
The only sure way to protect yourself against this is to remove the HKEY_CLASSES_ROOT\aim registry key, which will disable the AIM protocol altogether, as explained here.
I wonder how long until these will be deployed domestically, around various government buildings (such as the White House, the US Capitol, or the Pentagon).
They will be touted as the perfect solution to a problem with heretofore only imperfect solutions (until, say, a passenger aircraft is accidentally shot down of course).
The biggest differences between this and previous missile defense systems are cost and multiple-use capability. You're not talking about using multi-million dollar missiles to shoot down incoming missiles, so you don't need to be so selective about when firing the thing off. And if you miss, you can try again... and again.
As a defensive tool, these are, quite honestly, awesome. As an accident-waiting-to-happen in the hands of an overly-enthusiastic operator, they are, well, a little bit scary I guess.
Why erect non-human readable signs where they get in the way? What are the benefits of me being able to see this large thing other than to know something is there?
There are lots of reasons. For example, a bus stop might have a timetable with one of these symbols next to each entry. You'd just hold your phone up to the one you want to check, and it would connect to the proper web page and show you where that bus is on its route and how long until it reaches your location. Instantly. No special buttons to press or codes to enter, and with no expensive hardware needing to be installed at the bus stop.
The idea is that you can use the static, printed data (the barcode) to retrieve dynamic data (the bus location and how long until its arrival)--not just to retrieve more static data. Static data would still be printed, human readable as always, on the sign in the first place.
And, remember, web pages can be interactive, too; you can send information back to the company or organization whose barcode you just scanned through forms on the web page. So you could quickly order a product or service directly to your location.
...isn't this a much better application for something like RFID?
It really comes down to one word: Cost. Ink on paper is essentially free. If you're printing a sign anyway, there's no additional cost to include a barcode. Yes, RFID is cheap, but ink is cheaper.
This kind of thing crops up now and again in lots of fields. It's basically the same problem that keeps being predicted with our Interstate Highway system. There's a safe limit as to the speed that we can have cars travelling, and if the highways fill up, bumper to bumper all moving at that speed, we've reached capacity.
The most obvious solution there is the same as the obvious solution here: Add more lanes. If you have thirty-two lanes of traffic instead of one, you've increased your capacity roughly 32 times. Same situation here: Transmit 32 bits in parallel (simultaneously) down distinct channels, rather than in serial (one at a time).
Just as building more lanes is expensive, here the expense comes in multiplying all of the necessary hardware to handle wider data busses for as far down the path as necessary to deal with more data in parallel. Right now, we've got parallel busses inside our PCs, but the bits often end up serialized at some point inside our processors, down at the microcode level. All of these bottlenecks need to be categorized and eliminated to overcome such a theoretical data transfer limit. It will be neither easy nor inexpensive, especially when we decide we need to send and process, say, 2048 bits in parallel in order to meet our data processing needs. At some point, it becomes more economical to separate things on a higher level (add more processors, or add more PCs), similar to building additional highways rather than just adding lanes.
I don't believe this man is an idiot. Instead, it sounds like he is suffering from OCD (Obsessive Compulsive Disorder). Specifically, it sounds like a form of hoarding (I hope that link can handle the traffic--Google cache of the main page here), where one simply cannot refuse to buy things that are presented to him or her.
The Internet, and spam, is just providing an unfortunately convenient way for him to acquire these purchases.
The article explains that he used to hunt rummage sales, thift stores, and flea markets, then turned to the Internet after hurting his back. He buys on eBay, and via spam. Spam is just one part of his disease, and it made an interesting story. From the tour his wife gave of their apartment, it sounds like he doesn't need most of the stuff he buys--a typical symptom of hoarding.
Another symptom will be that he is unable to throw away things that he has purchased (like those boxes of vitamins), even if he doesn't need them or they are no longer of value.
OCD medication is usually ineffective for hoarding, but counseling can help.
At any rate, he does not respresent a typical email user, but at the same time, he is not alone. It is unfortunate, but there are people with these kinds of disorders out there, and they play right into the hands of spammers and telemarketers. The sad thing is when people take advantage of them.
Attempting to assign CS to a nonexecutable (read/write data) segment, i.e. attempting to execute code in a segment not specifically marked as executable, generates an exception. (See also this presentation for an overview of this and many other x86 security features, most of which are, admittedly, ignored by both Windows and Linux.)
And, by the way, this feature has been around since protected mode was introduced on the 80386. That was in 1985, almost 20 years ago.
I highly doubt that Linux authors would think twice about breaking buggy apps to force the issue.
Actually, Solar Designer's non-executable stack patches have been consistently refused for inclusion in the official Linux kernel, for at least six years now, even though every sysadmin I know uses them on any Linux machine put out on the Internet. (Making the stack non-executable eliminates the threat from many buffer overrun problems, for example.) Most all of his other patches have made their way to the kernel quickly (his security hardening patch is now a fraction of the size it used to be, because most of it has been moved into the official kernel over the years).
One reason given repeatedly for not including a non-executable stack in the stock kernel was because things like GCC's trampolines, used in nested functions (something hardly any programs use, as it's not standard C), don't necessarily work when the stack is non-executable without special considerations. And those special considerations can't catch 100% of the cases, and those programs crash unless they are redesigned. Which is, of course, exactly the opposite of what you suggested.
(There is also the "false-sense-of-security" argument: the patch has not been included because it gives admins a false sense of security. I find this weak. In a nonperfect system, every additional bit of security helps. Having passwords on systems also give us a false sense of security, when there are other ways for hackers to break in. But we still put passwords on our machines.)
Actually, only the Itanium and AMD K8 are affected by this immediately; Microsoft isn't yet marking memory nonexcutable by default on the good old x86 processors that we all use.
Regardless, it is trivial for developers to update their code for things like JIT compilers, with a simple function like this:
I added that piece of code to my company's JIT compiler some years ago, just to ensure that the proper flags were set. I figured Microsoft would eventually switch to nonexecutable data and stack segments, much like the OpenWall project has done with their Linux patches. Glad to see Microsoft is finally taking the first steps.
Look what happens if you add support for "Caller ID for Email" to your software:
Microsoft and its Affiliates hereby grant you ("Licensee") a... license... to make, use, sell, offer to sell, import, and otherwise distribute Licensed Implementations,
provided, Licensee... grants Microsoft and all other Specification Licensees, a reciprocal fully paid, royalty-free, non-exclusive, worldwide, nontransferable, non-sublicenseable, license under Necessary Claims of Licensee to make, use, sell, offer to sell, import, and otherwise distribute Licensed Implementations.
So by building support for "Caller ID for Email" into your software, you suddenly give Microsoft an unlimited license to use and sell it. And, in fact, not only Microsoft, but everyone else who writes software that supports "Caller ID for Email."
There is a word for this: Insane.
No thanks. I'll stick with SPF--especially since the two are essentially identical, just a slightly different parsing format.
...one of the reasons that the xbox has been a success is the ability to rip your music onto it and play it in your favorite games. This feature demands a hard drive...
Not true. At all.
Almost certainly, this feature will be kept, but simply moved onto your network instead. You will instead rip MP3s or WMAs onto your Windows PC and then share the folders over your wired or wireless LAN. Your X-Box will access your music files over the network.
And, it turns out, this makes considerably more sense than the current hard drive solution: What is the point of keeping separate MP3 collections on your PC and on your X-Box?
I've noticed this kind of thing happens all the time in life, and I really am starting to dislike it: Everything is going just fine, you do nothing wrong, someone else screws up--completely outside of your control--and it takes you time and money to fix it.
I've gotten half-a-million-dollar tax bills because my state double-issued a taxpayer ID. I've been pulled over for speeding by the police within seconds of entering a highway, not even yet at highway speed, because my car happened to be the same model as someone they had clocked miles up the highway. I've had my ISP cancel my account when their credit card processor double-billed my card and marked the chargeback of the second amount as nonpayal.
And now, I've got this to worry about, too. I have around twenty domain names with GoDaddy.
I really empathize with you. This just sucks.
I really hope that you can get the $250 refunded, talking with the right people at GoDaddy.com. Please keep us updated, if not here, then in your Slashdot journal.
I can't imagine that they could keep the $250; I am amazed they actually made you pay it in the first place.
If you cannot get them to refund the $250 within the next week or so, here is what I would recommend:
Transfer all of your domain names elswhere (once you find a registrar of course). Then once they have been successfully transferred, dispute the $250 charge with your credit card company. You have 60 days from the date of your statement; so anywhere from 60 to 90 days from today, depending on when your next statement is sent out. It's as easy as filling out a form or writing a short letter and mailing it in. Your credit card company will side with you by default, that's how they work, and refund the money immediately. The burden of proof will then like with GoDaddy.com to show that they charged you this fee correctly; if what you have said is true, they will be unable to do it.
Of course it will be a hassle, transferring your domain names. Hopefully it won't come to that, and GoDaddy will step up to the plate, refund your $250, and apologize. Let us know what happens. I wish you the best.
(Oh, that's what I get when I accidentally hit the Enter key....)
Anyway...:-)... I meant to post a nice link to Actuality Systems. Their site has neat closeup color pictures of their system which works on the same technology as this Hitachi system, and which has been working since at least 2002; Hitachi has done nothing new, and from the specs that I can make out, their system actually seems to operate at a far lower resolution than Actuality's.
Microsoft WAS in the antivirus business a long time ago.
Microsoft included "MSAV.EXE"--Microsoft Anti-Virus--with MS-DOS 6.0 back in the early 90's.
It was, essentially, a cut-down derivative of Central Point Antivirus, which was actually developed by a company in Israel, not Central Point. Central Point was purchased by Symantec in 1994, and Microsoft quietly removed MSAV from their OS's when Symantec refused to supply updates and Yisrael Radai wrote his now famous paper outlining how it was deeply flawed.
Conveniently I have the same system configuration as ikewillis (dual 2.0 GHz Athlon MP), but am running Windows XP instead of Linux. I also have Intel C++ 8.0, which he used on Linux to generate his results.
So I ran the same tests that he ran under Linux under Windows. Here are my results from Intel C++ 8.0, with Profile Guided Optimization turned off (comparing to his with PGO on):
Integer performance: 6265 ms (he got 6340 ms) Floating point perfomance: 4547 ms (he got 5540 ms) 64-bit Integer preformance: 13547 ms (he got 27140 ms) Trig performance: 2250 ms (he got 2430 ms) I/O performance: 7360 ms (he got 1190 ms)
Running the same tests under Windows with PGO turned on, the numbers did not change except on the least-significant digits, so I won't bother to list those too. Before running the tests, I set the program to run at high priority on one processor to avoid unnecessary interference from other running applications, or unnecessary processor-jumping--although when I tried it without, there wasn't much of a difference (< 1%).
Conclusions? First, it seems the 64-bit integer performance problem is something that exists only for Intel C++ 8.0 on Linux, not Windows. Second, it seems stdlib I/O performance is significantly higher under Linux than under Windows for this benchmark.
Earthlink has an optional system like this, where unknown senders are blocked by default. They receive an autoreply giving them a URL to go to where they must enter the text from a CAPTCHA.
Unfortunately, the system does not work very well. My dad sells on eBay, and a buyer of one of his auctions had an Earthlink account, which blocked the message that told how much the shipping would be, where to send payment, etc. When my dad went to the specified URL, and entered the CAPTCHA text as requested he would simply get an error message that he had entered it incorrectly. He forwarded me the Earthlink email and asked me if it was just him; it wasn't; I couldn't get it to work either. The random string of numbers and letters was very distorted, and there were four possible meanings; I tried those plus at least ten more with no sucess. The message never got through.
There are many problems with this type of system. Consider: what if both parties have CAPTCHA-enabled accounts, from different providers? The confirmation messages from both parties get blocked. Smarter systems whitelist people as messages are sent to them, but as in the eBay case, the recipient had no way of knowing my dad's email until AFTER a message from him was received. It's a Catch-22.
And for people who are visually impaired, universal deployment of this system this makes email essentially impossible. Earthlink's page had a link "if you cannot see the picture, click here" and when you got to that they said to call their 1-800 number if you have any problems. Right.
Adding CAPTCHAs to everyone's email systems is NOT the way to solve the spam problem. We need a more realistic, permanent solution. For example, cryptographically authenticating the sender (the "From" field) at the level of the originating ISP (and rejecting messages from senders it cannot authenticate, by password or whatever means), and then having each relay in turn authenticating the previous relay if it trusts it. Headers can be inserted in the emails, signing the previous headers with private encryption keys with their public counterparts obtainable from the ISPs by simple DNS lookups. This will build a chain of trust, which stops when a message gets outside of the sender's network, and therefore allows the original sender to be properly identified back through their ISP. Once we know who messages are from, people can be held responsible. And at that point, anti-spam laws can handle the rest.
There are three disparate levels of security you need to consider, and it is advisable to take a three-tiered approach to the problem.
First, for employees and others who have trusted access to your network, the answer is not to poke holes in your firewall. Rather, the answer is simple, just three letters. VPN. By setting up a secure, encrypted, authenticating channel, you bring your trusted users into your network. From your point of view and theirs, it is as if their machines were physically located on the other side of your firewall--just like having the machines right in your building.
Second, for business partners and contractors who need limited access to a subset of services, but whom you do not trust fully, the answer is quite likely also a VPN, but not directly into your network. For services provided to these people, you want everything from your end first going through application-level firewalls, and then through the VPN, over the Internet, to them.
Using a VPN in these cases prevents random hackers from entering your network on these levels.
Finally, for the general public who simply need access to your web site, the ideal situation is to simply host the web site on a network entirely separate from yours--possibly not even in the same city. Use an application-level firewall to help prevent things like buffer overflows. Then, if your web server needs to retrieve information from other systems on your network, have it communicate over a VPN, just like the second-level users mentioned above--that is, through additional levels of firewalls to machines not directly on your primary network. (Basically, you shouldn't consider your web servers as trusted machines, since they are out there, "in the wild.")
By following this approach, you expose nothing more than is necessary to the world, and greatly mitigate the risk of intrusion.
Although this article refers to embedded systems, the earlier Booting Linux Faster article contained an overlooked post by TornSheetMetal, who had a great idea on how to make Linux, or any operating system start up faster on any system.
Simply run every startup script simultaneously, but have each script block until its dependencies have started. Nothing waits longer than it needs to, and there is no need for additional complex systems to check and manage dependencies.
This is VERY easy to do with daemontools and svok (both written by D.J. Bernstein, the author of qmail). Switch over and you'll never go back.
On the way out they pick up a MAG Innovision 17-inch CRT monitor for a hundred bucks, hop in the Chevy Malibu rental, and floor it back to the Burkes'.
I, too, had a 17" MAG CRT monitor--in 1990. These so called "geeks" should be able to do a heck of a lot better than a 17" CRT if their goal is to bring the family "up to date." I lost all faith in them after reading that. As far as I can tell, they did nothing more than buy whatever was on page two of the Best Buy circular that week.
The idea as a whole is intriguing, but with posers instead of real geeks, it's pretty pointless.
The need for immortality is obvious. Given an infinite lifespan--with all of its infinite possibilities--there will finally be a non-zero probability that the average Slashdot reader will be able to lose his virginity.
Slashdot Mirror
I'll give 10:1 odds that Futuremark simply compiled their benchmark with Intel's C++ compiler.
I wrote a detailed explanation back in 2005 about how the Intel C++ compiler generates separate code paths for memory operations to make AMD processors appear significantly slower, and how you can trick the compiled code into believing your AMD processor is an Intel one to see incredibly increased performance. See this article for additional details.
I noticed this problem back in January of 2004, with Intel C++ 8.0, and went through heck over nine months with Intel's customer support to get it fixed until I eventually had to abandon their compiler.
... If the performance of memcpy/memset only are improved for Pentium III will that satisfy you?"
On any non-Intel processors, it specifically included an alternate code path for "memcpy" that actually used "rep movsb" to copy one byte at a time, instead of (for example) "rep movsd" to copy a doubleword at a time (or MMX instructions to copy quadwords). This was probably the most brain-dead memcpy I'd ever seen, and was around 4X slower than even a typical naive assembly memcpy:
push ecx
shr ecx, 2
rep movsd
pop ecx
and ecx, 3
rep movsb
They responded with completely ridiculous answers, such as:
"Our 8.0 memcpy was indeed optimized for a Pentium(r)4 Processor,when we reworked this routine we used the simplest, most robust, and straightforward implementation for older processors so that we didn't need the extra code to check for alignment, length, overlap, and other conditions."
BS. I went and added the following line to the beginning of my source code:
extern "C" int __intel_cpu_indicator;
then I added:
__intel_cpu_indicator = -512;
to the "main" function.
This forced Intel C++ to use the "Pentium 4" memcpy regardless of which processor in in the machine. It turns out that their special "Pentium 4" memcpy which I tested thoroughly in all kinds of situations, and it worked perfectly fine on an AMD Athlon and a Pentium III. I pointed this out to them.
I received the following response:
"The fast mempcy is over 2000 lines of hand coded assembly, with lots of special cases where different code paths are chosen based on relative alignment of the source and destination.
I answered "No," saying that I needed support for AMD processors as well. I also gave them a copy of my own memcpy routine that was 50% faster than theirs--and just used MMX. They closed the support issue and did nothing to resolve it.
I switched back to Visual C++.
Since it may not be obvious to all readers, be aware that when you can make a program crash by feeding it bad data, you can typically further manipulate the data you are sending it to take control of the program. That means a security hole. This is how buffer-overruns work. You can't always do it, but you can think of each way you can crash a program as a little "crack" in its exterior. If you can figure out a way to pry apart the crack, you've got yourself a hole.
.NET languages, rather than programming in straight C like the others) which as a side effect prevented such problems.
So many of these "bugs" in Mozilla, Opera, Lynx, and Links are likely security holes as well.
It is interesting, then, to see that Internet Explorer did so well on this, with its notoriously bad history on security. My first instinct would be that the HTML parsing engine in Internet Explorer was written by a different team of programmers than worked on the rest of the software, and they used proper programming techniques (such as RAII in C++, or perhaps used one of their
Let's hope that all these bugs are taken care of in the other browsers quickly before the black hats find ways to make use of them.
Any web page can launch URLs of the form aim:goaway?message=Anything+goes+here by many different means without user intervention:
- Redirect response codes
- Meta redirect tags
- Frames
- iframes
- Javascript popups
Any one of those methods will change your away message automatically, without any confirmation on your part. And if the part in the message= section is more than 1024 characters, arbitrary code can be executed on your machine.The only sure way to protect yourself against this is to remove the HKEY_CLASSES_ROOT\aim registry key, which will disable the AIM protocol altogether, as explained here.
Who gets the prize money then? :-D
Everybody, link back here!
They will be touted as the perfect solution to a problem with heretofore only imperfect solutions (until, say, a passenger aircraft is accidentally shot down of course).
The biggest differences between this and previous missile defense systems are cost and multiple-use capability. You're not talking about using multi-million dollar missiles to shoot down incoming missiles, so you don't need to be so selective about when firing the thing off. And if you miss, you can try again ... and again.
As a defensive tool, these are, quite honestly, awesome. As an accident-waiting-to-happen in the hands of an overly-enthusiastic operator, they are, well, a little bit scary I guess.
The idea is that you can use the static, printed data (the barcode) to retrieve dynamic data (the bus location and how long until its arrival)--not just to retrieve more static data. Static data would still be printed, human readable as always, on the sign in the first place.
And, remember, web pages can be interactive, too; you can send information back to the company or organization whose barcode you just scanned through forms on the web page. So you could quickly order a product or service directly to your location.
It really comes down to one word: Cost. Ink on paper is essentially free. If you're printing a sign anyway, there's no additional cost to include a barcode. Yes, RFID is cheap, but ink is cheaper.This kind of thing crops up now and again in lots of fields. It's basically the same problem that keeps being predicted with our Interstate Highway system. There's a safe limit as to the speed that we can have cars travelling, and if the highways fill up, bumper to bumper all moving at that speed, we've reached capacity.
The most obvious solution there is the same as the obvious solution here: Add more lanes. If you have thirty-two lanes of traffic instead of one, you've increased your capacity roughly 32 times. Same situation here: Transmit 32 bits in parallel (simultaneously) down distinct channels, rather than in serial (one at a time).
Just as building more lanes is expensive, here the expense comes in multiplying all of the necessary hardware to handle wider data busses for as far down the path as necessary to deal with more data in parallel. Right now, we've got parallel busses inside our PCs, but the bits often end up serialized at some point inside our processors, down at the microcode level. All of these bottlenecks need to be categorized and eliminated to overcome such a theoretical data transfer limit. It will be neither easy nor inexpensive, especially when we decide we need to send and process, say, 2048 bits in parallel in order to meet our data processing needs. At some point, it becomes more economical to separate things on a higher level (add more processors, or add more PCs), similar to building additional highways rather than just adding lanes.
Just do what I did, on 2.80:
Delete in_mod.dll from the "Plugins" directory.
Hole: Patched.
Who uses MOD/XM files anymore anyways?
The Internet, and spam, is just providing an unfortunately convenient way for him to acquire these purchases.
The article explains that he used to hunt rummage sales, thift stores, and flea markets, then turned to the Internet after hurting his back. He buys on eBay, and via spam. Spam is just one part of his disease, and it made an interesting story. From the tour his wife gave of their apartment, it sounds like he doesn't need most of the stuff he buys--a typical symptom of hoarding.
Another symptom will be that he is unable to throw away things that he has purchased (like those boxes of vitamins), even if he doesn't need them or they are no longer of value.
OCD medication is usually ineffective for hoarding, but counseling can help.
At any rate, he does not respresent a typical email user, but at the same time, he is not alone. It is unfortunate, but there are people with these kinds of disorders out there, and they play right into the hands of spammers and telemarketers. The sad thing is when people take advantage of them.
Wrong. Get your facts straight.
Bit 43 of the x86 segment descriptor table specifies whether a memory segment is executable.
Attempting to assign CS to a nonexecutable (read/write data) segment, i.e. attempting to execute code in a segment not specifically marked as executable, generates an exception. (See also this presentation for an overview of this and many other x86 security features, most of which are, admittedly, ignored by both Windows and Linux.)
And, by the way, this feature has been around since protected mode was introduced on the 80386. That was in 1985, almost 20 years ago.
Actually, Solar Designer's non-executable stack patches have been consistently refused for inclusion in the official Linux kernel, for at least six years now, even though every sysadmin I know uses them on any Linux machine put out on the Internet. (Making the stack non-executable eliminates the threat from many buffer overrun problems, for example.) Most all of his other patches have made their way to the kernel quickly (his security hardening patch is now a fraction of the size it used to be, because most of it has been moved into the official kernel over the years).
One reason given repeatedly for not including a non-executable stack in the stock kernel was because things like GCC's trampolines, used in nested functions (something hardly any programs use, as it's not standard C), don't necessarily work when the stack is non-executable without special considerations. And those special considerations can't catch 100% of the cases, and those programs crash unless they are redesigned. Which is, of course, exactly the opposite of what you suggested.
(There is also the "false-sense-of-security" argument: the patch has not been included because it gives admins a false sense of security. I find this weak. In a nonperfect system, every additional bit of security helps. Having passwords on systems also give us a false sense of security, when there are other ways for hackers to break in. But we still put passwords on our machines.)
Actually, only the Itanium and AMD K8 are affected by this immediately; Microsoft isn't yet marking memory nonexcutable by default on the good old x86 processors that we all use.
Regardless, it is trivial for developers to update their code for things like JIT compilers, with a simple function like this:
I added that piece of code to my company's JIT compiler some years ago, just to ensure that the proper flags were set. I figured Microsoft would eventually switch to nonexecutable data and stack segments, much like the OpenWall project has done with their Linux patches. Glad to see Microsoft is finally taking the first steps.
(From Microsoft's license.)
So by building support for "Caller ID for Email" into your software, you suddenly give Microsoft an unlimited license to use and sell it. And, in fact, not only Microsoft, but everyone else who writes software that supports "Caller ID for Email."
There is a word for this: Insane.
No thanks. I'll stick with SPF--especially since the two are essentially identical, just a slightly different parsing format.
Not true. At all.
Almost certainly, this feature will be kept, but simply moved onto your network instead. You will instead rip MP3s or WMAs onto your Windows PC and then share the folders over your wired or wireless LAN. Your X-Box will access your music files over the network.
And, it turns out, this makes considerably more sense than the current hard drive solution: What is the point of keeping separate MP3 collections on your PC and on your X-Box?
This whole thing bothers me to no end.
I've noticed this kind of thing happens all the time in life, and I really am starting to dislike it: Everything is going just fine, you do nothing wrong, someone else screws up--completely outside of your control--and it takes you time and money to fix it.
I've gotten half-a-million-dollar tax bills because my state double-issued a taxpayer ID. I've been pulled over for speeding by the police within seconds of entering a highway, not even yet at highway speed, because my car happened to be the same model as someone they had clocked miles up the highway. I've had my ISP cancel my account when their credit card processor double-billed my card and marked the chargeback of the second amount as nonpayal.
And now, I've got this to worry about, too. I have around twenty domain names with GoDaddy.
I really empathize with you. This just sucks.
I really hope that you can get the $250 refunded, talking with the right people at GoDaddy.com. Please keep us updated, if not here, then in your Slashdot journal. I can't imagine that they could keep the $250; I am amazed they actually made you pay it in the first place.
If you cannot get them to refund the $250 within the next week or so, here is what I would recommend:
Transfer all of your domain names elswhere (once you find a registrar of course). Then once they have been successfully transferred, dispute the $250 charge with your credit card company. You have 60 days from the date of your statement; so anywhere from 60 to 90 days from today, depending on when your next statement is sent out. It's as easy as filling out a form or writing a short letter and mailing it in. Your credit card company will side with you by default, that's how they work, and refund the money immediately. The burden of proof will then like with GoDaddy.com to show that they charged you this fee correctly; if what you have said is true, they will be unable to do it.
Of course it will be a hassle, transferring your domain names. Hopefully it won't come to that, and GoDaddy will step up to the plate, refund your $250, and apologize. Let us know what happens. I wish you the best.
(Oh, that's what I get when I accidentally hit the Enter key....)
Anyway... :-) ... I meant to post a nice link to Actuality Systems. Their site has neat closeup color pictures of their system which works on the same technology as this Hitachi system, and which has been working since at least 2002; Hitachi has done nothing new, and from the specs that I can make out, their system actually seems to operate at a far lower resolution than Actuality's.
http://www.computerworld.com/hardwaretopics/hardwa re/story/0,10801,69675,00.html
Microsoft WAS in the antivirus business a long time ago.
Microsoft included "MSAV.EXE"--Microsoft Anti-Virus--with MS-DOS 6.0 back in the early 90's.
It was, essentially, a cut-down derivative of Central Point Antivirus, which was actually developed by a company in Israel, not Central Point. Central Point was purchased by Symantec in 1994, and Microsoft quietly removed MSAV from their OS's when Symantec refused to supply updates and Yisrael Radai wrote his now famous paper outlining how it was deeply flawed.
Conveniently I have the same system configuration as ikewillis (dual 2.0 GHz Athlon MP), but am running Windows XP instead of Linux. I also have Intel C++ 8.0, which he used on Linux to generate his results.
So I ran the same tests that he ran under Linux under Windows. Here are my results from Intel C++ 8.0, with Profile Guided Optimization turned off (comparing to his with PGO on):
Running the same tests under Windows with PGO turned on, the numbers did not change except on the least-significant digits, so I won't bother to list those too. Before running the tests, I set the program to run at high priority on one processor to avoid unnecessary interference from other running applications, or unnecessary processor-jumping--although when I tried it without, there wasn't much of a difference (< 1%).
Conclusions? First, it seems the 64-bit integer performance problem is something that exists only for Intel C++ 8.0 on Linux, not Windows. Second, it seems stdlib I/O performance is significantly higher under Linux than under Windows for this benchmark.
Earthlink has an optional system like this, where unknown senders are blocked by default. They receive an autoreply giving them a URL to go to where they must enter the text from a CAPTCHA.
Unfortunately, the system does not work very well. My dad sells on eBay, and a buyer of one of his auctions had an Earthlink account, which blocked the message that told how much the shipping would be, where to send payment, etc. When my dad went to the specified URL, and entered the CAPTCHA text as requested he would simply get an error message that he had entered it incorrectly. He forwarded me the Earthlink email and asked me if it was just him; it wasn't; I couldn't get it to work either. The random string of numbers and letters was very distorted, and there were four possible meanings; I tried those plus at least ten more with no sucess. The message never got through.
There are many problems with this type of system. Consider: what if both parties have CAPTCHA-enabled accounts, from different providers? The confirmation messages from both parties get blocked. Smarter systems whitelist people as messages are sent to them, but as in the eBay case, the recipient had no way of knowing my dad's email until AFTER a message from him was received. It's a Catch-22.
And for people who are visually impaired, universal deployment of this system this makes email essentially impossible. Earthlink's page had a link "if you cannot see the picture, click here" and when you got to that they said to call their 1-800 number if you have any problems. Right.
Adding CAPTCHAs to everyone's email systems is NOT the way to solve the spam problem. We need a more realistic, permanent solution. For example, cryptographically authenticating the sender (the "From" field) at the level of the originating ISP (and rejecting messages from senders it cannot authenticate, by password or whatever means), and then having each relay in turn authenticating the previous relay if it trusts it. Headers can be inserted in the emails, signing the previous headers with private encryption keys with their public counterparts obtainable from the ISPs by simple DNS lookups. This will build a chain of trust, which stops when a message gets outside of the sender's network, and therefore allows the original sender to be properly identified back through their ISP. Once we know who messages are from, people can be held responsible. And at that point, anti-spam laws can handle the rest.
There are three disparate levels of security you need to consider, and it is advisable to take a three-tiered approach to the problem.
First, for employees and others who have trusted access to your network, the answer is not to poke holes in your firewall. Rather, the answer is simple, just three letters. VPN. By setting up a secure, encrypted, authenticating channel, you bring your trusted users into your network. From your point of view and theirs, it is as if their machines were physically located on the other side of your firewall--just like having the machines right in your building.
Second, for business partners and contractors who need limited access to a subset of services, but whom you do not trust fully, the answer is quite likely also a VPN, but not directly into your network. For services provided to these people, you want everything from your end first going through application-level firewalls, and then through the VPN, over the Internet, to them.
Using a VPN in these cases prevents random hackers from entering your network on these levels.
Finally, for the general public who simply need access to your web site, the ideal situation is to simply host the web site on a network entirely separate from yours--possibly not even in the same city. Use an application-level firewall to help prevent things like buffer overflows. Then, if your web server needs to retrieve information from other systems on your network, have it communicate over a VPN, just like the second-level users mentioned above--that is, through additional levels of firewalls to machines not directly on your primary network. (Basically, you shouldn't consider your web servers as trusted machines, since they are out there, "in the wild.")
By following this approach, you expose nothing more than is necessary to the world, and greatly mitigate the risk of intrusion.
Although this article refers to embedded systems, the earlier Booting Linux Faster article contained an overlooked post by TornSheetMetal, who had a great idea on how to make Linux, or any operating system start up faster on any system.
Simply run every startup script simultaneously, but have each script block until its dependencies have started. Nothing waits longer than it needs to, and there is no need for additional complex systems to check and manage dependencies.
This is VERY easy to do with daemontools and svok (both written by D.J. Bernstein, the author of qmail). Switch over and you'll never go back.
The idea as a whole is intriguing, but with posers instead of real geeks, it's pretty pointless.
The need for immortality is obvious. Given an infinite lifespan--with all of its infinite possibilities--there will finally be a non-zero probability that the average Slashdot reader will be able to lose his virginity.