I setup a OpenGL workstation using all rounded cables from 1coolpc.com and, other than the fact that the cables don't fit very tightly and liek to fall out if stressed, everything seems to be going alright for the company that purchased the puter. I have 2 of them in my system as well, which seem to be working. Perhaps it was something else?
Here he goes again. Look at old BSD and Linux stories and this message is mirrored for almost every non-MS operating system.
This guy seems to have a template where he just pastes an OS or product name and then inserts some random tid bits of info. Hope he's having fun.
"I know my theories and findings are hard for you to accept because they are so original and extraordinary. But one day in the future, you will see that I am right. You will be foreced to accept my invention as millions of people around you tell you that I am right."
This is a classic logical fallacy called "Appeal to majority."
While the philosophy of logic defines only 9 basic statements, rules of inference, that decide whether a statement is logical; there are infinite types of statements that are illogical. Alex seems to have hit one that is so common it is named.
X number of people say it's true, therefore, it must be true!
Windows 98 must be the best OS! Period!
Blonde hair must be the prettiest! Period!
People that put on rings whose magnatism doesn't even penetrate 1/4" of skin say that they are immortal so they must be! Period!
Don't worry. The scientific method was devised for people just like this.
PC Power and Cooling (www.pcpowercooling.com) makes a series of power supplies called "Silencer" which can be purchased from $69 for the 150W model to $199 for the 400W.
These power supplies are generally considered the highest quality among those that care about power supplies (even better than SevenTeam, Sparkle, Antec, etc) but they are also by far the most expensive that I have ever seen.
If you want to go a cheaper route and have some saudering skillz, go to www.heatsinkfactory.com and get Panasonic Panaflo fans to replace the noisy ones in your power supply (and wherever else.
You can also make a cardboard "exhaust pipe" and tape it to the back of your power supply (or attach it using a more attractive method if you prefer). This incolves simply getting 4 walls of cardboard (a small box with the bottom and top cut out will work fine) and setting the box up to surrount the output of the power supply. Keep it reasonably close to the actual fan or there won't be any difference.
Troll? No, I think he has a good point. What has Microsoft written that was original? They stole the wheeled mouse, they stole Windows and the idea of a GUI as well as its interface elements, and they didn't even write the first BASIC interpreter. (They hired an outside contractor--look at the back of the manual!)
I do not recall any original ideas that they have created. Microsoft has attained an art-like mastery of implementation and, of course, marketing--but can anybody name anything that they have invented and not stolen?
I am serious, I would be curious to know if they have ever actually been innovative (By Webster's definition, not Microsoft's)
The topic is lzip, the lossless compression library ("Who really needs to uncompress their data anyway?"). The message was about a use for lzip (image compression)
Pointless, yes. Offtopic, no.
What evidence do you have that NASA uses MySQL?
Even if NASA does make use of MySQL, people tend to be impressed by anything if "NASA" uses it. Do you honestly think that NASA has to deal with databases as large as Visa? Is NASAs use of something really taht impressive? Earlier there was a/. article detailing how the international space station may be using laptops for life support.
Should Visa run their MySQL database on laptops?
Furthermore, do you think that NASA exclusively uses MySQL for ALL of their database needs? It is a matter of using the right tool for the right job.
OT/FYI
When compiling for the Athlon, this generally yields the fastest code:
-s -static -O3 -Wall -mpentiumpro -march=pentiumpro -malign-functions=4 -fexpensive-optimizations -funroll-loops -malign-double -fschedule-insns2 -mwide-multiply -fomit-frame-pointer
Occasionally something will need to be compiled with an option that is incompatible with at least one of those flags (like -fomit-frame-pointer when using debugging options), so just remove the offending portion.
Note that the above options technically slightly break Intel's published AB I(Application Binary Interface), but it is actually an oversight on Intel's part and doesn't cause compatibility problems on the processor level. (It may if your shared libraries aren't compiled in a similar manner, which may be a big deal to you, but I just recompiled mine. Speed is good.
Note: If you don't want your code to be insanely hugemongous, remove "-static"
Well, I look at your example like this:
The boards, nails, etc. are the processor opcodes. You CAN go lower level (Building your own processor/making your own materials) but that's getting a bit rediculous. Then it eventually gets down to "Did you really/MAKE/ that silicon, or was it produced in the nuclear fire of stars billions of years ago?.
Now, if you build a house and have an outside company make your walls and floors for you then truck them in, that (IMHO) is more representative of using premade functions.
The problem is, you don't really KNOW how those floors and walls were made. How many C programmers know, (really KNOW) how, say, malloc(); works? (Especially in DOS) Those that think you do, try to implement it into a compiler. (That's not to say that no/.'er could of course)
I agree with your comment about the true creative process of writing the program. I was more refering to understanding how everything works and truely being able to take full credit for the program.
I understand that writing C without any #includes is impractical and that many (most) truely excellent programmers use other people's functions.
If you don't feel that using standard lib functions is, in a light sort of way, cheating... I have no problem with that. I use standard library calls all the time. They are what makes development in C so much faster than development in assembly.
I just personally feel that a program is not truely mine if I have done so. (It's nothing that I lose sleep over though)
In addition to the other gentleman's links, try:
http://www.hornet.org/
and do a search for "in2k" (no space, make sure you include the www. in the URL)
Have fun.
Some of the demos are very humbling.
Most programmers that I consider truely skilled still use assembly for a variety of tasks. Many things are MUCH easier to do in assembler than in any high-level language (Just try writing self-morphing code in C--And yes that is useful, it is very difficult to crack self-morphing programs)
Assembly language is control. Control over every instruction that the processor recieves. Control over every byte of memory that is shifted throughout memory.
You can control the exact number of bytes that your program occupies.
You can make TINY programs.
How about a webserver in under 600 bytes? (Granted, it can't outperform Apache...) How about a GLibC clone in under a meg? I have seen demos from the Finnish assembly competitions that included such feats as real time raytracing of a translucent sphere on a 386. How about much of the first level of Interplay's Descent in exactly 4096 bytes? (Including music!)
Want to talk to hardware, directly, without any overhead? Try accessing the 64-bit register that counts the number of clocks so far on modern IA CPUs without ASM. You can't do that in an HLL because nobody has done it for you yet. HLLs are largely about piecing together others' work into a new pattern. In ASM, it's just you and the CPU.
Many people also use assembly because it is also great for people who want to not only code a program, but actually know how it works. you can write a program in C you say? Or PERL, Eiffel, or whatever? I consider using function calls cheating in a way. Did you write any of those standard C functions that you are using?
If not, did you really write that program, or did you simply arrange the smaller programs of others (functions) in such a way that they work differently than the particular arrangement of another person's program.
(I'm not saying that function calls are bad--they sure speed up development--I am trying to make a point about assembly)
As an added benefit, those who code in assembly are generally better at coding in HLLs because they know better how those HLLs work. Knowing how they work means being able to write faster code. For example, if you are using a language that has no tolower() equivalent, you can write something like:
switch(ch[0]) {
case 'A':
ch[0] = 'a';
case 'B':
ch[0] = 'b';
...etc...
The coder that learned how his system works at a binary level might choose the much faster:
The bitwise OR doesn't even take a clock cycle to execute (but admittedly it is harder to read)
discLamer: I'm not trying to tell anybody that their HLL coding skills are unimportant or easy. I'm not saying that HLLs are bad. (My favorite language is C). I am saying that many very skilled programmers still use assembly because it is very good at certain things that no other language can do well or at all. I am also saying that assembly is not dead. Just unpopular. I am also posting this at 4:45AM and have had no sleep or caffiene for quite some time. Just ignore me.
Here are a some answers to some common complaints about assembly language blatantly stolen from Randall Hyde's book, "The Art of Assembly Language Programming." If you are interested, the whole book is freely available at http://webster.cs.ucr.edu/Page_asm/ArtofAssembly/f wd/fwd.html
-=-=-=-
Assembly is hard to learn.
So is any language you don't already know. Try learning (really learning) APL, Prolog, or Smalltalk sometime. Once you learn Pascal, learning another language like C, BASIC, FORTRAN, Modula-2, or Ada is fairly easy because these languages are quite similar to Pascal. On the other hand, learning a dissimilar language like Prolog is not so simple. Assembly language is also quite different from Pascal. It will be a little harder to learn than one of the other Pascal-like languages. However, learning assembly isn't much more difficult than learning your first programming language.
Assembly is hard to read and understand.
It sure is, if you don't know it. Most people who make this statement simply don't know assembly. Of course, it's very easy to write impossible-to-read assembly language programs. It's also quite easy to write impossible-to-read C, Prolog, and APL programs. With experience, you will find assembly as easy to read as other languages.
Assembly is hard to debug.
Same argument as above. If you don't have much experience debugging assembly language programs, it's going to be hard to debug them. Remember what it was like finding bugs in your first Pascal (or other HLL) programs? Anytime you learn a new programming language you'll have problems debugging programs in that language until you gain experience.
Assembly is hard to maintain.
C programs are hard to maintain. Indeed, programs are hard to maintain period. Inexperienced assembly language programmers tend to write hard to maintain programs. Writing maintainable programs isn't a talent. It's a skill you develop through experience.
Assembly language is hard.
This statement actually has a ring of truth to it. For the longest time assembly language programmers wrote their programs completely from scratch, often "re-inventing the wheel." HLL programmers, especially C, Ada, and Modula-2 programmers, have long enjoyed the benefits of a standard library package which solves many common programming problems. Assembly language programmers, on the other hand, have been known to rewrite an integer output routine every time they need one. This book does not take that approach. Instead, it takes advantage of some work done at the University of California, Riverside: the UCR Standard Library for 80x86 Assembly Language Programmers. These subroutines simplify assembly language just as the C standard library aids C programmers. The library source listings are available electronically via Internet and various other communication services as well as on a companion diskette.
Assembly language programming is time consuming.
Software engineers estimate that developers spend only about thirty percent of their time coding a solution to a problem. Even if it took twice as much time to write a program in assembly versus some HLL, there would only be a fifteen percent difference in the total project completion time. In fact, good assembly language programmers do not need twice as much time to implement something in assembly language. It is true using a HLL will save some time; however, the savings is insufficient to counter the benefits of using assembly language.
Improved compiler technology has eliminated the need for assembly language.
This isn't true and probably never will be true. Optimizing compilers are getting better every day. However, assembly language programmers get better performance by writing their code differently than they would if they were using some HLL. If assembly language programmers wrote their programs in C and then translated them manually into assembly, a good C compiler would produce equivalent, or even better, code. Those who make this claim about compiler technology are comparing their hand-compiled code against that produced by a compiler. Compilers do a much better job of compiling than humans. Then again, you'll never catch an assembly language programmer writing "C code with MOV instructions." After all, that's why you use C compilers.
Today, machines are so fast that we no longer need to use assembly.
It is amazing that people will spend lots of money to buy a machine slightly faster than the one they own, but they won't spend any extra time writing their code in assembly so it runs faster on the same hardware. There are many raging debates about the speed of machines versus the speed of the software, but one fact remains: users always want more speed. On any given machine, the fastest possible programs will be written in assembly language.
If you need more speed, you should use a better algorithm rather than switch to assembly language.
Why can't you use this better algorithm in assembly language? What if you're already using the best algorithm you can find and it's still too slow? This is a totally bogus argument against assembly language. Any algorithm you can implement in a HLL you can implement in assembly. On the other hand, there are many algorithms you can implement in assembly which you cannot implement in a HLL.
Machines have so much memory today, saving space using assembly is not important.
If you give someone an inch, they'll take a mile. Nowhere in programming does this saying have more application than in program memory use. For the longest time, programmers were quite happy with 4 Kbytes. Later, machines had 32 or even 64 Kilobytes. The programs filled up memory accordingly. Today, many machines have 32 or 64 megabytes of memory installed and some applications use it all. There are lots of technical reasons why programmers should strive to write shorter programs, though now is not the time to go into that. Let's just say that space is important and programmers should strive to write programs as short as possible regardless of how much main memory they have in their machine.
Assembly language is not portable.
This is an undeniable fact. An 80x86 assembly language program written for an IBM PC will not run on an Apple Macintosh. Indeed, assembly language programs written for the Apple Macintosh will not run on an Amiga, even though they share the same 680x0 microprocessor. If you need to run your program on different machines, you'll have to think long and hard about using assembly language. Using C (or some other HLL) is no guarantee that your program will be portable. C programs written for the IBM PC won't compile and run on a Macintosh. And even if they did, most Mac owners wouldn't accept the result.
Don't flame me too much... This is my first post on/.!
Slashdot Mirror
I setup a OpenGL workstation using all rounded cables from 1coolpc.com and, other than the fact that the cables don't fit very tightly and liek to fall out if stressed, everything seems to be going alright for the company that purchased the puter. I have 2 of them in my system as well, which seem to be working. Perhaps it was something else?
Here he goes again. Look at old BSD and Linux stories and this message is mirrored for almost every non-MS operating system.
This guy seems to have a template where he just pastes an OS or product name and then inserts some random tid bits of info. Hope he's having fun.
"I know my theories and findings are hard for you to accept because they are so original and extraordinary. But one day in the future, you will see that I am right. You will be foreced to accept my invention as millions of people around you tell you that I am right."
This is a classic logical fallacy called "Appeal to majority."
While the philosophy of logic defines only 9 basic statements, rules of inference, that decide whether a statement is logical; there are infinite types of statements that are illogical. Alex seems to have hit one that is so common it is named.
X number of people say it's true, therefore, it must be true!
Windows 98 must be the best OS! Period!
Blonde hair must be the prettiest! Period!
People that put on rings whose magnatism doesn't even penetrate 1/4" of skin say that they are immortal so they must be! Period!
Don't worry. The scientific method was devised for people just like this.
Try any of these out:
PC Power and Cooling (www.pcpowercooling.com) makes a series of power supplies called "Silencer" which can be purchased from $69 for the 150W model to $199 for the 400W.
These power supplies are generally considered the highest quality among those that care about power supplies (even better than SevenTeam, Sparkle, Antec, etc) but they are also by far the most expensive that I have ever seen.
If you want to go a cheaper route and have some saudering skillz, go to www.heatsinkfactory.com and get Panasonic Panaflo fans to replace the noisy ones in your power supply (and wherever else.
You can also make a cardboard "exhaust pipe" and tape it to the back of your power supply (or attach it using a more attractive method if you prefer). This incolves simply getting 4 walls of cardboard (a small box with the bottom and top cut out will work fine) and setting the box up to surrount the output of the power supply. Keep it reasonably close to the actual fan or there won't be any difference.
Hope this helps
Troll? No, I think he has a good point. What has Microsoft written that was original? They stole the wheeled mouse, they stole Windows and the idea of a GUI as well as its interface elements, and they didn't even write the first BASIC interpreter. (They hired an outside contractor--look at the back of the manual!) I do not recall any original ideas that they have created. Microsoft has attained an art-like mastery of implementation and, of course, marketing--but can anybody name anything that they have invented and not stolen? I am serious, I would be curious to know if they have ever actually been innovative (By Webster's definition, not Microsoft's)
The topic is lzip, the lossless compression library ("Who really needs to uncompress their data anyway?"). The message was about a use for lzip (image compression) Pointless, yes. Offtopic, no.
What evidence do you have that NASA uses MySQL? Even if NASA does make use of MySQL, people tend to be impressed by anything if "NASA" uses it. Do you honestly think that NASA has to deal with databases as large as Visa? Is NASAs use of something really taht impressive? Earlier there was a /. article detailing how the international space station may be using laptops for life support.
Should Visa run their MySQL database on laptops?
Furthermore, do you think that NASA exclusively uses MySQL for ALL of their database needs? It is a matter of using the right tool for the right job.
OT/FYI When compiling for the Athlon, this generally yields the fastest code: -s -static -O3 -Wall -mpentiumpro -march=pentiumpro -malign-functions=4 -fexpensive-optimizations -funroll-loops -malign-double -fschedule-insns2 -mwide-multiply -fomit-frame-pointer Occasionally something will need to be compiled with an option that is incompatible with at least one of those flags (like -fomit-frame-pointer when using debugging options), so just remove the offending portion. Note that the above options technically slightly break Intel's published AB I(Application Binary Interface), but it is actually an oversight on Intel's part and doesn't cause compatibility problems on the processor level. (It may if your shared libraries aren't compiled in a similar manner, which may be a big deal to you, but I just recompiled mine. Speed is good. Note: If you don't want your code to be insanely hugemongous, remove "-static"
I lied. There IS text in here. MWAHAHAHAHA!
Well, I look at your example like this: The boards, nails, etc. are the processor opcodes. You CAN go lower level (Building your own processor/making your own materials) but that's getting a bit rediculous. Then it eventually gets down to "Did you really /MAKE/ that silicon, or was it produced in the nuclear fire of stars billions of years ago?.
Now, if you build a house and have an outside company make your walls and floors for you then truck them in, that (IMHO) is more representative of using premade functions.
The problem is, you don't really KNOW how those floors and walls were made. How many C programmers know, (really KNOW) how, say, malloc(); works? (Especially in DOS) Those that think you do, try to implement it into a compiler. (That's not to say that no /.'er could of course)
I agree with your comment about the true creative process of writing the program. I was more refering to understanding how everything works and truely being able to take full credit for the program.
I understand that writing C without any #includes is impractical and that many (most) truely excellent programmers use other people's functions.
If you don't feel that using standard lib functions is, in a light sort of way, cheating... I have no problem with that. I use standard library calls all the time. They are what makes development in C so much faster than development in assembly.
I just personally feel that a program is not truely mine if I have done so. (It's nothing that I lose sleep over though)
In addition to the other gentleman's links, try: http://www.hornet.org/ and do a search for "in2k" (no space, make sure you include the www. in the URL) Have fun. Some of the demos are very humbling.
Most programmers that I consider truely skilled still use assembly for a variety of tasks. Many things are MUCH easier to do in assembler than in any high-level language (Just try writing self-morphing code in C--And yes that is useful, it is very difficult to crack self-morphing programs)
f wd/fwd.html
/.!
Assembly language is control. Control over every instruction that the processor recieves. Control over every byte of memory that is shifted throughout memory.
You can control the exact number of bytes that your program occupies.
You can make TINY programs.
How about a webserver in under 600 bytes? (Granted, it can't outperform Apache...) How about a GLibC clone in under a meg? I have seen demos from the Finnish assembly competitions that included such feats as real time raytracing of a translucent sphere on a 386. How about much of the first level of Interplay's Descent in exactly 4096 bytes? (Including music!)
Want to talk to hardware, directly, without any overhead? Try accessing the 64-bit register that counts the number of clocks so far on modern IA CPUs without ASM. You can't do that in an HLL because nobody has done it for you yet. HLLs are largely about piecing together others' work into a new pattern. In ASM, it's just you and the CPU.
Many people also use assembly because it is also great for people who want to not only code a program, but actually know how it works. you can write a program in C you say? Or PERL, Eiffel, or whatever? I consider using function calls cheating in a way. Did you write any of those standard C functions that you are using?
If not, did you really write that program, or did you simply arrange the smaller programs of others (functions) in such a way that they work differently than the particular arrangement of another person's program.
(I'm not saying that function calls are bad--they sure speed up development--I am trying to make a point about assembly)
As an added benefit, those who code in assembly are generally better at coding in HLLs because they know better how those HLLs work. Knowing how they work means being able to write faster code. For example, if you are using a language that has no tolower() equivalent, you can write something like:
switch(ch[0]) {
case 'A':
ch[0] = 'a';
case 'B':
ch[0] = 'b';
...etc...
The coder that learned how his system works at a binary level might choose the much faster:
if((ch[0] >= 'A') && (ch[0] = 'Z')) ch[0] = (ch[0] | ch[0]);
The bitwise OR doesn't even take a clock cycle to execute (but admittedly it is harder to read)
discLamer: I'm not trying to tell anybody that their HLL coding skills are unimportant or easy. I'm not saying that HLLs are bad. (My favorite language is C). I am saying that many very skilled programmers still use assembly because it is very good at certain things that no other language can do well or at all. I am also saying that assembly is not dead. Just unpopular. I am also posting this at 4:45AM and have had no sleep or caffiene for quite some time. Just ignore me.
Here are a some answers to some common complaints about assembly language blatantly stolen from Randall Hyde's book, "The Art of Assembly Language Programming." If you are interested, the whole book is freely available at http://webster.cs.ucr.edu/Page_asm/ArtofAssembly/
-=-=-=-
Assembly is hard to learn.
So is any language you don't already know. Try learning (really learning) APL, Prolog, or Smalltalk sometime. Once you learn Pascal, learning another language like C, BASIC, FORTRAN, Modula-2, or Ada is fairly easy because these languages are quite similar to Pascal. On the other hand, learning a dissimilar language like Prolog is not so simple. Assembly language is also quite different from Pascal. It will be a little harder to learn than one of the other Pascal-like languages. However, learning assembly isn't much more difficult than learning your first programming language.
Assembly is hard to read and understand.
It sure is, if you don't know it. Most people who make this statement simply don't know assembly. Of course, it's very easy to write impossible-to-read assembly language programs. It's also quite easy to write impossible-to-read C, Prolog, and APL programs. With experience, you will find assembly as easy to read as other languages.
Assembly is hard to debug.
Same argument as above. If you don't have much experience debugging assembly language programs, it's going to be hard to debug them. Remember what it was like finding bugs in your first Pascal (or other HLL) programs? Anytime you learn a new programming language you'll have problems debugging programs in that language until you gain experience.
Assembly is hard to maintain.
C programs are hard to maintain. Indeed, programs are hard to maintain period. Inexperienced assembly language programmers tend to write hard to maintain programs. Writing maintainable programs isn't a talent. It's a skill you develop through experience.
Assembly language is hard.
This statement actually has a ring of truth to it. For the longest time assembly language programmers wrote their programs completely from scratch, often "re-inventing the wheel." HLL programmers, especially C, Ada, and Modula-2 programmers, have long enjoyed the benefits of a standard library package which solves many common programming problems. Assembly language programmers, on the other hand, have been known to rewrite an integer output routine every time they need one. This book does not take that approach. Instead, it takes advantage of some work done at the University of California, Riverside: the UCR Standard Library for 80x86 Assembly Language Programmers. These subroutines simplify assembly language just as the C standard library aids C programmers. The library source listings are available electronically via Internet and various other communication services as well as on a companion diskette.
Assembly language programming is time consuming.
Software engineers estimate that developers spend only about thirty percent of their time coding a solution to a problem. Even if it took twice as much time to write a program in assembly versus some HLL, there would only be a fifteen percent difference in the total project completion time. In fact, good assembly language programmers do not need twice as much time to implement something in assembly language. It is true using a HLL will save some time; however, the savings is insufficient to counter the benefits of using assembly language.
Improved compiler technology has eliminated the need for assembly language.
This isn't true and probably never will be true. Optimizing compilers are getting better every day. However, assembly language programmers get better performance by writing their code differently than they would if they were using some HLL. If assembly language programmers wrote their programs in C and then translated them manually into assembly, a good C compiler would produce equivalent, or even better, code. Those who make this claim about compiler technology are comparing their hand-compiled code against that produced by a compiler. Compilers do a much better job of compiling than humans. Then again, you'll never catch an assembly language programmer writing "C code with MOV instructions." After all, that's why you use C compilers.
Today, machines are so fast that we no longer need to use assembly.
It is amazing that people will spend lots of money to buy a machine slightly faster than the one they own, but they won't spend any extra time writing their code in assembly so it runs faster on the same hardware. There are many raging debates about the speed of machines versus the speed of the software, but one fact remains: users always want more speed. On any given machine, the fastest possible programs will be written in assembly language.
If you need more speed, you should use a better algorithm rather than switch to assembly language.
Why can't you use this better algorithm in assembly language? What if you're already using the best algorithm you can find and it's still too slow? This is a totally bogus argument against assembly language. Any algorithm you can implement in a HLL you can implement in assembly. On the other hand, there are many algorithms you can implement in assembly which you cannot implement in a HLL.
Machines have so much memory today, saving space using assembly is not important.
If you give someone an inch, they'll take a mile. Nowhere in programming does this saying have more application than in program memory use. For the longest time, programmers were quite happy with 4 Kbytes. Later, machines had 32 or even 64 Kilobytes. The programs filled up memory accordingly. Today, many machines have 32 or 64 megabytes of memory installed and some applications use it all. There are lots of technical reasons why programmers should strive to write shorter programs, though now is not the time to go into that. Let's just say that space is important and programmers should strive to write programs as short as possible regardless of how much main memory they have in their machine.
Assembly language is not portable.
This is an undeniable fact. An 80x86 assembly language program written for an IBM PC will not run on an Apple Macintosh. Indeed, assembly language programs written for the Apple Macintosh will not run on an Amiga, even though they share the same 680x0 microprocessor. If you need to run your program on different machines, you'll have to think long and hard about using assembly language. Using C (or some other HLL) is no guarantee that your program will be portable. C programs written for the IBM PC won't compile and run on a Macintosh. And even if they did, most Mac owners wouldn't accept the result.
Don't flame me too much... This is my first post on
sivar@NoSpam.email.REMOVE.com