The simplistic MS argument will me, "See, this company used GPL software, and all it got in return it was to be sued and hit with a preliminary injunction!"
Yeah right. We all know MS would never sue anybody about pirate copies of Windows. If a company decides to sell computers with Windows preinstalled, and not pay MS for the software, of course MS wouldn't sue. MS don't want anybody to be afraid of using Windows.
Re:I hope someone will be examining it closely
on
Paid To Spam
·
· Score: 1
It strikes me that this could be very useful for the writers of various anti-spam filters.
How much help would one million identical spam mails be in development of anti-spam filters? If you got one million different spam mails it could be a good thing, but that is not going to be the case. Of course it might still help a bit.
maybe not a firewall, but a honeypot so the app THINKS it is sending spam...
Anybody who wants to do that? Feel free to use my honeypot.
(smtphoneypot.c) Put it on a Linux box acting as firewall, and use an iptables rule to redirect all outgoing SMTP connections to the honeypot. You might need to let a few test emails through to avoid them noticing. Hopefully it will work if you let their application contact their own mailserver, but no other mailserver.
One time (a few years ago, I don't remember exactly when) a flaw was discovered in OpenSSH. It was anounced that a bug had been found, and that a patch would be released one week later, such that every distributor could release them at the same time and administrators would be prepared to install them. That aproach was very similar to what this article describes. (Yes I actually read it)
It was a complete failure. It lead to some of the worst criticism the project had ever experienced. And they ended up releasing the patch earlier than announced, not because of the criticism, but because exploit code was being written despite of the patch not being made generally available.
most of which cannot be reached through the current PageRank
algorithm
What kind of nonsense is that? The PageRank algorithm doesn't decide which pages are in their archive, it merely decide an ordering so you see the most relevant entries first. I know about three reasons for some pages not being accessible in search engines. Either people will not allow the search engines to index them. Or there are no links to the pages, so there is no way to know about their existence. And finally servers/pages can be so broken that google will give up on them. All of this is unrelated to the PageRank.
Besides I don't belive any of those estimates about the number of pages on the web. There is aproximately an infinite amount of dynamically generated pages. And if you want to not count those, you end up with the problem of defining exactly what is dynamically generated. Slashdot is a good example of a site where it is very difficult to draw the line between static and dynamic content. And even if you do a great deal of work in eliminating most dynamic content from your indexing, there will be something you have missed. So if you keep crawling you will find some infinite trees of dynamic content. I have tried writing a crawler, so I know how much broken stuff you will find. We also found some nasty sites which we discovered only because of URLs overflowing the 4KB limit we had decided to enforce.
The only way to avoid getting bitten by dynamic content while crawling is to limit your crawl to the most relevant pages. Randomized breath first or highest rank first will do well in avoiding infinite dynamic trees.
So the facts are, that there are many pages, which no search engine knows about. Nobody knows exactly how many, and any estimate will be unreliable. But what google have indexed probably is aproximately the 4 billion most relevant pages of what is inside the reach of any search engine.
Will a kernel compiled for AMD64 work without modifications on IA32e? I don't know. But my guess is that at the very latest one month after IA32e become widely available Linux the kernel will boot on both and automatically detect the CPU and behave as required. It might work out of the box, as that would be an advantage to Intel. Fixing Windows to work with a slightly incompatible CPU would not be as easy as with Linux.
there are only so many ways to extend a 32-bit arch to 64-bit.
There are enough ways that it would be unlikely for two companies to come up with the same solution by chance. The original 16 bit architecture had only eight general purpose registers, that number remained the same when it was later extended to 32 bits. AMD decided to put in more general purpose registers. So the first decission to make is whether to have 8, 16, or 32 general purpose registers. Next come the decission about to what extent you need the ability to access smaller parts of the registers. The original 16 bit architecture would allow you to access each half of the first four general purpose registers directly. There is no way you would allow direct access to each byte in 16 different 64 bit general purpose registers. But do you allow access to only the least significant 8, 16, and 32 bits in each 64 bit register, or do you allow access to higher parts in some cases. You need direct access to AH, BH, CH, and DH for backward compatibility. But that is not necesarilly required for any of the new 64 bit instructions. Then comes the decission about addressing modes, layout of opcodes, how to know how many bits an instruction actually operates on. With the 32 bit extension the later was determined by the CPU mode as well as an optional instruction prefix. Even though you want backward compatibility with 8 bit code, 16 bit code, and 32 bit code, the 64 bit code doesn't have to be backward compatible as there was nothing to be backward compatible with, so an entirely new instruction set would have been an option. But similarity with the existing 32 bit instruction set might be desired. That is a hell of a lot of decissions to make. And unless you make all of them the same, you will end up with two fundementally different and far from being compatible instruction sets. And even if all decissions I have talked about here have been made the same, some bitfidling still remains.
Shouldn't cause any major problems. Only the kernel have to deal with this when setting up page tables. Any correctly written program will work the same on both processors. What will be the difference is, that some buggy code and some security exploits will work only on Intel and not on AMD.
KWallet sounds like a nice tool. Does anybody here know how the security is? Does it encrypt the data using the password as key?
When I read about the noatun voice removal feature I started wondering, is that one as fake as the one in xmms that really just computes the difference between the left and right sound channel?
Kompare looks nice too, I'm surely going to try that next time I need to look at a patch. But actually the screenshot in the article shows a typical problem with diff generated patches. It notice there are identical lines with bracets and match them. But actually they shouldn't have been matched. The one on the right really should have been matched with an indented version on the left. Functionally this is rarely a problem, but visually it is confusing. Now what would be really kool would be if they included a feature to tell the program to match particular lines and then save a fixed patch. BTW my guess is that when Kompare is asked to compare two files, what it really does is just calling the command line version of diff to create a patch, and then view that (Not that there is anything wrong with that, it fits perfectly with the Unix philosophy).
Karamba looks kool, I need to try that one day. And the scripting features too.
The problem is not in their color, but usually in their rather small 'viewing angle'
The blue and green leds on my Compaq laptop have the same viewing angle, which is about 180 degrees. So while it might not apply to all blue leds, it certainly is possible to make a blue led with a large viewing angle.
Re:Well... blue LEDs are okay...
on
The Blues for LEDs
·
· Score: 2, Funny
I'm sure I could imagine a beowulf cluster of those
Actually when I'm sitting next to our beowulf cluster I can see sixteen blue leds on the raid box connected to our fileserver running Linux. And can you imagine how distracting that can be? But hey, it looks cool.
Why do you think people still use windows even with the viruses, the bugs, the interop problems, etc., etc...??
People keep using Windows because of all the interoperability problems Microsoft introduce. Sad but true. The interoperatbility problems means it is expensive to switch away from Windows. What too few people have realized is, that the cost of switching away probably isn't going to get smaller, and the cost of staying might very well be increasing. So in the long run I think a lot of companies would do better the sooner they switch away from Microsoft.
I think a lot of innocent people would kill you (or anybody else for the matter) for 2 billion dollar. Of course you might argue they wouldn't be innocent then, but they are innocent right now, and they will be until you give them the 2 billion dollars. Which of them who would actually go that far for 2 billion dollars I don't think you could find out before trying.
Linux needs to do something *groundbreaking* that Windows
doesn't
With Linux I can get a userinterface that is way more userfriendly than what Windows can offer me. Isn't that enough to make Linux a good alternative to Windows. I hear people saying Windows is more userfriendly than Linux. But I disagree.
why should I be a guinea pig?
Why should I be Microsoft's guinea pig? Or even Microsoft's <something worse>?
two things that when crypted yield the same result
That can't happen. Would you by any chance be thinking of something else? Possibly a hash rather than an encryption. The fact that you can decrypt proves that the encryption cannot produce collisions. That is for any m we know that D(E(m))=m so if E(m1)=E(m2) then it must be the case that D(E(m1))=D(E(m2)) which is the same as m1=m2.
I don't know. I didn't make it to the end. Halfway down the first page I realized this guy probably doesn't know what he is talking about. The page says "Most modern operating systems, which include Linux, are composed of two parts: a small central piece called the "kernel" and a larger piece that has the applications and drivers." Well, first of all, drivers are part of the kernel. So neither did he make the distinction right, nor did he tell us why it is really important. I have often seen this distinction made to explain a bit about the naming and version numbering. He didn't even make that point. And he continues to explain "Linux distributions have pretty much the same kernel, but differ in the applications they offer." Which is not entirely true either. At least a large part of the applications will be the same between two distributions. And the kernel itself will usually not be exactly the same, so in the end the kernel might be as different as everything else.
Isn't that what mad cow disease is? A mirrored protein that get used as a template which our body replicates.
Some years ago I did hear about a theory stating that this disease was caused by a protein. But I don't remember the details. Being a protein makes it a bit harder to get rid of than vira and bacteria.
If we are looking on only one of the possible differences, chances probably will be 50-50 (unless for some unknown reason life is more likely in one direction than the other). But there are multiple differences. So if each of them have a 50-50 probability distribution, how are those correlated? If a specific direction of the DNA implies a specific direction of everything else, I would agree with you. But otherwise the chances of every single factor being identical could be smaller.
I'd expect us to be able to see that pretty easily - eg: Totally different fundamental mechanisms for just about everything.
Even if the mechanisms are the same, there could be a difference. Many chemical structures involving carbon can exist in two different variants, that are each others mirror image. In life on earth a lot of those apear only in one variant. In some cases the mirror image of something existing in our bodies would actually be toxic. And AFAIK the torsion of DNA in every living cell here on earth is the same direction. Now even if life did evolve in the same way independendly on Earth and Mars, what are the chances that all of those structures would be the same direction in Earth life and Martian life? If we found life on Mars with DNA that was mirrored compared to our DNA, what would that tell us?
I agree that would be a solution, and exactly the same I would have suggested. It means webbrowsers would be lying and violating the standards. But that is life, it is necesarry. Too bad referrer is being abused in ways making this necesarry. Referrer headers were nice, but if it continue like this we will have to say goodbye to them. I hope this attribute will only be used to circumvent abuse of referrer and not be abused in itself. Well, I'm afraid that last comment is dreaming. I know anything that can be abused will be abused. Perhaps the way to go would be to get a standard requiring servers to serve the same content independent of the referrer header. Wouldn't solve the problem, but at least that would mean we only had to violate the standard when communicating with servers violating the standard themselves.
I'm talking about ONE virus that can infect a Windows machine, then propagate onto a linux machine and infect that, and so on.
It would be possible to do. But it would of course take at least twice as much work to make it. And I haven't heard of any. Even if the two OSes run on the same hardware, it would be hard to take advantage of, as system calls are different. If you want to attack a large range of different systems a virtual machine layer would make the task simpler. I think even with just two systems you might find that the virtual machine aproach is simpler. It is possible to target three or more systems without a virtual machine, but it gets complicated. Basically the complexity of a native virus would be quadratic in the number of target systems where the virtual machine version would be linear.
Two different systems means you must attack in two different ways. This also opens the possibility for a worm/virus hybrid. It could act as a worm on Linux systems and a virus on Windows systems. But you could go even further, you wouldn't have to limit yourself to one attack against each system. You could include ten different attacks against Windows, two different attacks against Linux, and one attack agains MacOS if you wanted to.
The attack is performed in the usual way through either a vulnurable network serive or by modifying the executable. The code to do this would be running on top of the virtual machine. You'd have to try the different attacks against systems, and each time you perform an attack, you transfer the apropriate virtual machine implementation for the target, and afterwards the program for the virtual machine.
Of course this wouldn't be as efficient as the worms we are seeing today. I mean you don't transfer such a pice of malware in a single UDP packet. Talk about bloatware worms anyone? It is not like todays worms need to transfer a MB of code to perform an infection, which I think you could easilly end up with if you want a single worm to target every vulnurability out there.
Slashdot Mirror
But I choose to distribute my program as a binary patch.
Last time I checked patches where text files. So what do you mean by a binary patch?
The simplistic MS argument will me, "See, this company used GPL software, and all it got in return it was to be sued and hit with a preliminary injunction!"
Yeah right. We all know MS would never sue anybody about pirate copies of Windows. If a company decides to sell computers with Windows preinstalled, and not pay MS for the software, of course MS wouldn't sue. MS don't want anybody to be afraid of using Windows.
It strikes me that this could be very useful for the writers of various anti-spam filters.
How much help would one million identical spam mails be in development of anti-spam filters? If you got one million different spam mails it could be a good thing, but that is not going to be the case. Of course it might still help a bit.
maybe not a firewall, but a honeypot so the app THINKS it is sending spam...
Anybody who wants to do that? Feel free to use my honeypot. (smtphoneypot.c) Put it on a Linux box acting as firewall, and use an iptables rule to redirect all outgoing SMTP connections to the honeypot. You might need to let a few test emails through to avoid them noticing. Hopefully it will work if you let their application contact their own mailserver, but no other mailserver.
One time (a few years ago, I don't remember exactly when) a flaw was discovered in OpenSSH. It was anounced that a bug had been found, and that a patch would be released one week later, such that every distributor could release them at the same time and administrators would be prepared to install them. That aproach was very similar to what this article describes. (Yes I actually read it)
It was a complete failure. It lead to some of the worst criticism the project had ever experienced. And they ended up releasing the patch earlier than announced, not because of the criticism, but because exploit code was being written despite of the patch not being made generally available.
most of which cannot be reached through the current PageRank algorithm
What kind of nonsense is that? The PageRank algorithm doesn't decide which pages are in their archive, it merely decide an ordering so you see the most relevant entries first. I know about three reasons for some pages not being accessible in search engines. Either people will not allow the search engines to index them. Or there are no links to the pages, so there is no way to know about their existence. And finally servers/pages can be so broken that google will give up on them. All of this is unrelated to the PageRank.
Besides I don't belive any of those estimates about the number of pages on the web. There is aproximately an infinite amount of dynamically generated pages. And if you want to not count those, you end up with the problem of defining exactly what is dynamically generated. Slashdot is a good example of a site where it is very difficult to draw the line between static and dynamic content. And even if you do a great deal of work in eliminating most dynamic content from your indexing, there will be something you have missed. So if you keep crawling you will find some infinite trees of dynamic content. I have tried writing a crawler, so I know how much broken stuff you will find. We also found some nasty sites which we discovered only because of URLs overflowing the 4KB limit we had decided to enforce.
The only way to avoid getting bitten by dynamic content while crawling is to limit your crawl to the most relevant pages. Randomized breath first or highest rank first will do well in avoiding infinite dynamic trees.
So the facts are, that there are many pages, which no search engine knows about. Nobody knows exactly how many, and any estimate will be unreliable. But what google have indexed probably is aproximately the 4 billion most relevant pages of what is inside the reach of any search engine.
The Linux kernel is precisely what I had in mind.
Will a kernel compiled for AMD64 work without modifications on IA32e? I don't know. But my guess is that at the very latest one month after IA32e become widely available Linux the kernel will boot on both and automatically detect the CPU and behave as required. It might work out of the box, as that would be an advantage to Intel. Fixing Windows to work with a slightly incompatible CPU would not be as easy as with Linux.
there are only so many ways to extend a 32-bit arch to 64-bit.
There are enough ways that it would be unlikely for two companies to come up with the same solution by chance. The original 16 bit architecture had only eight general purpose registers, that number remained the same when it was later extended to 32 bits. AMD decided to put in more general purpose registers. So the first decission to make is whether to have 8, 16, or 32 general purpose registers. Next come the decission about to what extent you need the ability to access smaller parts of the registers. The original 16 bit architecture would allow you to access each half of the first four general purpose registers directly. There is no way you would allow direct access to each byte in 16 different 64 bit general purpose registers. But do you allow access to only the least significant 8, 16, and 32 bits in each 64 bit register, or do you allow access to higher parts in some cases. You need direct access to AH, BH, CH, and DH for backward compatibility. But that is not necesarilly required for any of the new 64 bit instructions. Then comes the decission about addressing modes, layout of opcodes, how to know how many bits an instruction actually operates on. With the 32 bit extension the later was determined by the CPU mode as well as an optional instruction prefix. Even though you want backward compatibility with 8 bit code, 16 bit code, and 32 bit code, the 64 bit code doesn't have to be backward compatible as there was nothing to be backward compatible with, so an entirely new instruction set would have been an option. But similarity with the existing 32 bit instruction set might be desired. That is a hell of a lot of decissions to make. And unless you make all of them the same, you will end up with two fundementally different and far from being compatible instruction sets. And even if all decissions I have talked about here have been made the same, some bitfidling still remains.
thus causing some compatibility issues?
Shouldn't cause any major problems. Only the kernel have to deal with this when setting up page tables. Any correctly written program will work the same on both processors. What will be the difference is, that some buggy code and some security exploits will work only on Intel and not on AMD.
KWallet sounds like a nice tool. Does anybody here know how the security is? Does it encrypt the data using the password as key?
When I read about the noatun voice removal feature I started wondering, is that one as fake as the one in xmms that really just computes the difference between the left and right sound channel?
Kompare looks nice too, I'm surely going to try that next time I need to look at a patch. But actually the screenshot in the article shows a typical problem with diff generated patches. It notice there are identical lines with bracets and match them. But actually they shouldn't have been matched. The one on the right really should have been matched with an indented version on the left. Functionally this is rarely a problem, but visually it is confusing. Now what would be really kool would be if they included a feature to tell the program to match particular lines and then save a fixed patch. BTW my guess is that when Kompare is asked to compare two files, what it really does is just calling the command line version of diff to create a patch, and then view that (Not that there is anything wrong with that, it fits perfectly with the Unix philosophy).
Karamba looks kool, I need to try that one day. And the scripting features too.
The problem is not in their color, but usually in their rather small 'viewing angle'
The blue and green leds on my Compaq laptop have the same viewing angle, which is about 180 degrees. So while it might not apply to all blue leds, it certainly is possible to make a blue led with a large viewing angle.
I'm sure I could imagine a beowulf cluster of those
Actually when I'm sitting next to our beowulf cluster I can see sixteen blue leds on the raid box connected to our fileserver running Linux. And can you imagine how distracting that can be? But hey, it looks cool.
Why do you think people still use windows even with the viruses, the bugs, the interop problems, etc., etc...??
People keep using Windows because of all the interoperability problems Microsoft introduce. Sad but true. The interoperatbility problems means it is expensive to switch away from Windows. What too few people have realized is, that the cost of switching away probably isn't going to get smaller, and the cost of staying might very well be increasing. So in the long run I think a lot of companies would do better the sooner they switch away from Microsoft.
I wouldn't kill innocent people
I think a lot of innocent people would kill you (or anybody else for the matter) for 2 billion dollar. Of course you might argue they wouldn't be innocent then, but they are innocent right now, and they will be until you give them the 2 billion dollars. Which of them who would actually go that far for 2 billion dollars I don't think you could find out before trying.
Linux needs to do something *groundbreaking* that Windows doesn't
With Linux I can get a userinterface that is way more userfriendly than what Windows can offer me. Isn't that enough to make Linux a good alternative to Windows. I hear people saying Windows is more userfriendly than Linux. But I disagree.
why should I be a guinea pig?
Why should I be Microsoft's guinea pig? Or even Microsoft's <something worse>?
Two messages can collide provided they use different keys.
Yes, that is correct. It shouldn't happen too often though, as that would be a sign of a weakness.
two things that when crypted yield the same result
That can't happen. Would you by any chance be thinking of something else? Possibly a hash rather than an encryption. The fact that you can decrypt proves that the encryption cannot produce collisions. That is for any m we know that D(E(m))=m so if E(m1)=E(m2) then it must be the case that D(E(m1))=D(E(m2)) which is the same as m1=m2.
This one had exploits long before the vulnerability was known to anyone but the hackers.
I'm still looking forward for the day when Microsoft learn about a vulnurability only because a worm starts deleting Windows installations.
... that's all fine but does it have bar graphs?
I don't know. I didn't make it to the end. Halfway down the first page I realized this guy probably doesn't know what he is talking about. The page says "Most modern operating systems, which include Linux, are composed of two parts: a small central piece called the "kernel" and a larger piece that has the applications and drivers." Well, first of all, drivers are part of the kernel. So neither did he make the distinction right, nor did he tell us why it is really important. I have often seen this distinction made to explain a bit about the naming and version numbering. He didn't even make that point. And he continues to explain "Linux distributions have pretty much the same kernel, but differ in the applications they offer." Which is not entirely true either. At least a large part of the applications will be the same between two distributions. And the kernel itself will usually not be exactly the same, so in the end the kernel might be as different as everything else.
Isn't that what mad cow disease is? A mirrored protein that get used as a template which our body replicates.
Some years ago I did hear about a theory stating that this disease was caused by a protein. But I don't remember the details. Being a protein makes it a bit harder to get rid of than vira and bacteria.
Wouldn't the chances be 50-50?
If we are looking on only one of the possible differences, chances probably will be 50-50 (unless for some unknown reason life is more likely in one direction than the other). But there are multiple differences. So if each of them have a 50-50 probability distribution, how are those correlated? If a specific direction of the DNA implies a specific direction of everything else, I would agree with you. But otherwise the chances of every single factor being identical could be smaller.
I'd expect us to be able to see that pretty easily - eg: Totally different fundamental mechanisms for just about everything.
Even if the mechanisms are the same, there could be a difference. Many chemical structures involving carbon can exist in two different variants, that are each others mirror image. In life on earth a lot of those apear only in one variant. In some cases the mirror image of something existing in our bodies would actually be toxic. And AFAIK the torsion of DNA in every living cell here on earth is the same direction. Now even if life did evolve in the same way independendly on Earth and Mars, what are the chances that all of those structures would be the same direction in Earth life and Martian life? If we found life on Mars with DNA that was mirrored compared to our DNA, what would that tell us?
You know that old saying, "you get what you pay for".
How much do I have to pay to get freedom?
<a href="http://slashdot.org" referrer="http://www.google.com">
I agree that would be a solution, and exactly the same I would have suggested. It means webbrowsers would be lying and violating the standards. But that is life, it is necesarry. Too bad referrer is being abused in ways making this necesarry. Referrer headers were nice, but if it continue like this we will have to say goodbye to them. I hope this attribute will only be used to circumvent abuse of referrer and not be abused in itself. Well, I'm afraid that last comment is dreaming. I know anything that can be abused will be abused. Perhaps the way to go would be to get a standard requiring servers to serve the same content independent of the referrer header. Wouldn't solve the problem, but at least that would mean we only had to violate the standard when communicating with servers violating the standard themselves.
I'm talking about ONE virus that can infect a Windows machine, then propagate onto a linux machine and infect that, and so on.
It would be possible to do. But it would of course take at least twice as much work to make it. And I haven't heard of any. Even if the two OSes run on the same hardware, it would be hard to take advantage of, as system calls are different. If you want to attack a large range of different systems a virtual machine layer would make the task simpler. I think even with just two systems you might find that the virtual machine aproach is simpler. It is possible to target three or more systems without a virtual machine, but it gets complicated. Basically the complexity of a native virus would be quadratic in the number of target systems where the virtual machine version would be linear.
Two different systems means you must attack in two different ways. This also opens the possibility for a worm/virus hybrid. It could act as a worm on Linux systems and a virus on Windows systems. But you could go even further, you wouldn't have to limit yourself to one attack against each system. You could include ten different attacks against Windows, two different attacks against Linux, and one attack agains MacOS if you wanted to.
The attack is performed in the usual way through either a vulnurable network serive or by modifying the executable. The code to do this would be running on top of the virtual machine. You'd have to try the different attacks against systems, and each time you perform an attack, you transfer the apropriate virtual machine implementation for the target, and afterwards the program for the virtual machine.
Of course this wouldn't be as efficient as the worms we are seeing today. I mean you don't transfer such a pice of malware in a single UDP packet. Talk about bloatware worms anyone? It is not like todays worms need to transfer a MB of code to perform an infection, which I think you could easilly end up with if you want a single worm to target every vulnurability out there.