if the values in the array are distributed randomly
That doesn't matter. The analysis never said anything about the distribution of the numbers in the array. You may assume a worst case distribution of the numbers in the array, and the algorithm still works. Probability is meassured over random choices made by the algorithm, not over inputs. So given an input, you can compute the probability that the algorithm fails, which is always going to be a small number. Then you take the input giving the highest error probability (and now we are no longer assuming random choices, but deterministically chosing the worst case input). Since all the probabilities are small, even the largest of them will be small. This way of analysing error probabilities shouldn't come as a surprise, because that is how it is always done when considering probalistic algorithms.
Both Intel and AMD have stated that they plan to add virtualization support to forthcoming CPUs... Xen will be able to support unmodified guest operating systems
I have read about those plans. Still I wonder how well the virtualization will work. So maybe they will be able to virtualize a CPU we know today, but will they also be able to virtualize themselves? If the new CPU cannot virtualize itself it won't be long before we see a new Windows version requiring the virtualization features, such that this new Windows version will run only directly on the hardware and not in the virtual environment. If that happens we will back in todays state. Unless it will be able to virtualize itself, I don't trust all the promises about what good it will do.
This was going on when I was in high school, 10 years ago.
I also heard about this stuff when I was in high school 10 years ago. Some of my friends had TI-85 calculators, but I don't think any of them actually ever overclocked it.
The real joy was in installing a hacked ROM through an overflow on the link cable and running games written in Z80 assembly.
I tried some of those. But it wasn't really about hacking the ROM. The ROM was never changed, and if you removed the batteries it would still be restored to its original state. Also the way the assembler programs were transfered to the calculator was not through an overflow, but rather through a backup feature the calculator had. These calculators had a link cable, and one of the usages for this link cable was to create a full backup of the RAM. This full backup could either be stored on a PC using a special link cable or transfered to another calculator using the standard link cable. Transfering such a backup to a calculator would overwrite anything already in the RAM.
Now the trick was to create a backup on your PC and manipulate it there before transfering it back to the calculator. Inserting ASM code was the easy part, AFAIR it would all be put inside string variables which the standard software allowed you to manipulate. Actually executing this ASM code was the neat trick. This calulator had too many functions to make all directly available, for that reason it had a custom menu where you could put five of those for quick access. Now this was implemented using a pointer to the actual code in ROM for the selected function. In the manipulated backup one of this pointers would be altered to point into RAM rather than into ROM.
Once the backup image was ready it could be transfered to a calculator. The only way to insall this software on the calculator was through a full restore. But that could even be transfered from one calculator to another. Once you had the basic menusystem to access the ASM programs, you could transfer individual programs between calculators using standard features in the ROM. One drawback of using those ASM programs was, that while they were running the calculator wouldn't automatically turn off after some minutes of idle time, so you could easilly run down the batteries and would then need to start from scratch.
I want to do frequent backups and keep them for a long time. Of course when I do that there will be a lot of redundancy, and I don't have infinite amounts of disk space. What is a good way to do backups and make sure you get not only the file contents but also permissions, ownership, timestamp, etc. right? I decided to use tar, because so far it has always gotten these things right. It turns out tar is not a very compact format, but it is very convenient for my algorithm to reduce redundancy. The point is that tar store everything in 512 byte blocks. Every file have a header in such a 512 byte block, and file contents is padded with nul bytes to a full number of blocks.
Obviously with daily backups there will be a lot of identical blocks. That is what I use in my software, every block written to the storage is compared against the existing data, and it is only written if it does not already exist. That way I get rid of large amounts of redundancy, and I just need to create some indexes to be able to reconstruct the original files. The most tricky part is how to find the existing blocks efficiently. The second tricky part is how to eliminate redundancy in the indexes. I think I'm doing quite well in both respects.
Currently I have 404GB of tar files in my storage, however the size of the storage is only 5.5GB. But the best part is, that this blocking is not only good for storing tar files, it also works very well with the Linux file system model. With a very simple driver based on block mapping, I can mount my storage as a file system and access all the tar files directly. I can even mount those tar files using tarfs (though tarfs still seems to be lacking a few important features). There is still a few things I need to change before I'm completely satisfied with my storage format. As soon as I don't see anymore reasons to change it, I will release it under GPL.
It is nigh-on impractical to guarantee that there has been no deviation or differnence between preproduction / staging envrionment and the live production environment which would cause problems like that.
There is an easy approach, which should work. Before doing your test you restore from the latest backup of your production system. Then you are reasonably sure the systems match, and at the same time you also have frequent testing of backup and recovery procedure.
Just curious, but why not change the old function to simply eliminate the problem
Probably that wasn't possible. The semaphore implementation in Linux is not trivial. First of all it have a fast path implemented in assembler, which is only a two instructions long. But that come with the cost of a very complicated implementation in case of contention. This give a good overall performance. But it may happen, that the caller of down continue while the up call is still accessing the semaphore. This is not a problem because you can still not make more down calls than up calls. However if the semaphore is removed from memory, you will have trouble with any up or down call not yet finished accessing the semaphore.
This is why completions were introduced. Completions are slightly simpler than semaphores, but the performance is worse. So completions should only be used where necesarry. In fact every access to the completion is protected by a spinlock. This means that even if there is not contention on the completion, there may be contention on the spinlock. Two concurrent up calls on a semaphore will both take the fast path, as long as they don't need to wakeup another process. However with completions, there is only a slow path.
or even just simply be an alias of the new function?
In the up_and_exit vs complete_and_exit case, that wouldn't have been possible, since they take different kinds of arguments. The up call takes a semaphore as argument, the complete call takes a completion as argument.
I could only assume the new function needed data not suplied in calls to the old function.
Kind of... you pass it a different data structure.
I don't know if a completion can do everything a semaphore can do. Maybe you would have gotten working code by using completions in every place where a semaphore was previously used. If that had worked, the fix could have been made without breaking compatibility. But it would come with a major performance penalty. It is not acceptable to introduce a huge overhead on thousands of semaphore users simply because a few rare cases have additional requirements. And you can't really seperate those needing completions from the rest without modifying the source code and recompiling it.
Re:Economic balance of freedom software cost.
on
Being Free is Hard to Do
·
· Score: 3, Informative
kernel developers intentionally and frequently break API/ABI compatibility between minor releases so as to "encourage" vendors to release drivers under non-proprietary licenses.
People keep saying that, but I have yet to see just a single case where it happened. Kernel interfaces do change, and they change for the better. But I have never seen a change, which happened just to encourage rease of driver sources.
Right now I can remember a single change between minor releases, somewhere in the 2.4 kernels the up_and_exit function was removed, and a new complete_and_exit was introduced. I don't know how many drivers where affected by that, but at least the USB driver had to be changed. Of course the change didn't happen to break compatibility. The purpose of up_and_exit was to avoid a race condition when removing a module which had a kernel thread running that needed to be stopped before removing the module. If the module had just called up to signal it was terminated, and afterwards called exit, the module code might have been removed before the up call returned and caused a kernel crash as it returned to an undefined address. Having the up_and_exit function solved that problem. But it turned out there was still a race condition. Though no code was accessed inside the module, the sempahore itself would be a part of the module, and it could be removed before up had finished accessing it. This is why completions were introduced, they are different from semaphores, and are designed exactly to avoid this problem. So every user of up_and_exit had to be changed to use complete_and_exit instead. Nothing would have prevented leaving up_and_exit in the kernel, but any user was known to have a race condition. Had the function been left in the kernel, a lot of those buggy users of it might not have been noticed. By removing up_and_exit all instances of the bug would be revealed, and could easilly be fixed.
This was just one example, there might be more. The point here, is that the change did not happen to intentionally break binary compatibility. The change happened to fix a problem. And while you might think it broke the compatibility, it really just revealed all the modules, that were already broken. And kernel developers frequently make changes to make debuging easier, that is part of the reason the code is of such a good quality.
The kernel developers don't intentionally break binary only modules, in fact it seems they ignore binary drivers as much as possible. If a change can improve the kernel, it happens. In stable branches such changes only happen if they are necesarry to fix a bug, or if they don't cause major breaking. If all drivers in the kernel can trivially be updated to the new interface, there is no reason not to make the change.
Does ISPs get sued because they have had child porn in the buffers on their routers? The freenet caches are no different. It is a different media and it is slower. But in both cases it is just a temporary storage for some information you are transfering between two parties, who you are not affiliated with.
The same thing could be done on a system running from a HD. Of course you have to pay attention to swap and temporary files, but it is not anymore difficult to do from a HD than from a CD. And the HD version is going to be faster than the CD version. But I guess Knoppix already supports this.
What would be even more interesting is the possibility to run untrackable stuff like that in parallel with a system that does fully use HD. Of course specifying who is allowed to use swap is the tricky part. Temporary files could be taken care of just by running the stuff in a chroot with no disk based file system mounted read-write.
The classic virus modified EXEs on disk, but didn't need to modify executable code in memory.
You are absolutely right. And that is why NX doesn't help preventing vira. It may prevent most classical worms though. Whether worms will find a way arround the protection is an open question. In theory the bugs may still be exploitable, but hopefully it will take longer time to write exploit code, so there will at least be time to patch your system. Protecting against vira modifying executables is easy, and it doesn't require the NX bit. You just have to ensure that you run all non-trusted programs under a user, that does not have write access to your executables.
SP2 adds NX "protection." While this adds protection against buffer overflows on the stack, it does nothing for overflows on the heap,
In Linux it is easier to use NX to protect the heap than to use NX to protect the stack. That is because on the heap, every allocation is explicitly marked executable or not executable. On the stack OTOH you don't have any way to know, if a particular page needs to be executable or not. Not all applications needs an executable stack, but gcc used to use the stack for trampolines, when you had a pointer to a nested function. Unless you can document, why it should be the other way arround in Windows, I don't believe it.
which can be just as bad.
It usually takes more work to exploit an overflow in the heap than in the stack, but as soon as working exploit code have been written, they are equally bad.
Also, if the return address is simply changed to an address on the heap, code in the heap can be executed.
Only if the heap is executable. You might find a usable function in the executable or a library, but you still need to pass arguments to really exploit it.
The heap has the executable bit, because of dynamic libraries loaded into the heap.
This is just plain wrong. The NX bit is about per page protection. Protecting an entire segment was always possible, it is just not usable in most cases.
Sad to say, but no matter how much you want to see that headline, it is not going to happen in 2005. A new and more secure Windows is something you might see in the headlines, however if that happens expect another headline when it gets hit by a nasty worm.
Maybe that could be a solution, use a sub domain as the actual mail address, and just prepend abuse@ as the address
I tried that, and it may help a bit, but you will still get spam. I tried exposing kasperd@ and abuse@ on the same domain equally much in my signature. In half a year 67 spam mails were sent to kasperd, 1 were sent to abuse, and 30 were sent to use. (Don't know how they got that idea). Anyway, it seems the address was not exposed enough.
On another domain the abuse address was used as from address in 151 usenet postings in the time from june 5th 2004 until the july 4th 2004. So far I have received 455 spam mails on the abuse address, and 5 spam mails sent to the Message-ID of some of my postings.
If you do, then Slashdot will become liable as they'll be linking to a site that links to copyright materials.
Don't laugh. Here in Denmark APG (the equivalent of RIAA or something like that) threatened to sue a man for a song that could be downloaded just eight links away from his page.
That sounds to be like a really inefficient form of greylisting.
It sure does. A greylistning is a better approach. And with greylistning you lose no legitimate emails (unless the sender use a seriously broken mail server). Before greylistning was introduced on our mail server approximately 90% of all incoming mail was removed by spamassassin. And that is even with a very high threshold, so a lot of spam still made it past the filter.
Once greylistning was introduced the amount of incoming mail dropped by a factor of about ten. And those are still filtered by spamassassin, though only 40% are filtered and 60% let through. In total that means 90% stopped by greylistning, 4% blocked by spamassassin, and 6% let through. And in my experience about half of those let through both filters are spam. I don't want to think about what my Inbox would look like without spam filtering.
If you can give someone a good bright flash before the one with which the picture is taken, that will contract their pupils and you won't see "red-eye".
Try that on me, and you will not be able to see what color the eyes have.
Re:Notice the whiteboard
on
SCO.com Defaced
·
· Score: 2, Funny
notice what the girl has written on the whiteboard: "Hacked by reallocl"
I think it says: "hacked by realloc(". I wonder what the original looked like. Was the girl also in the original? I can't find it anywhere (maybe sco can't either).
so I can take something compiled for a 2.4 kernel and it will run on a box still running a 1.0 kernel?
First of all you don't compile programs for a specific kernel. Most programs doesn't even call the kernel directly, but does so only through libraries. Assuming you have libraries and programs designed for 2.4, would you expect them to work on 1.0? I wouldn't. A lot of features have been added since then, your program is most likely going to use some of those. Besides 1.0 is really obsolete by now. I think you will have a very hard time finding a production system using anything older than 1.3.
But consider the other way around. Take a program and libraries written for the 1.3 kernel, I think there is a good chance it will work on 2.6. As long as it just use ordinary posix calls, I don't see what could go wrong. And you are not going to use anything else anyway, right? You do want your program to work on other posix systems as well. I have a program on my system which is available only in binary form. I have used that program since kernel version 2.2, and the same executable still works on 2.6.
Who says they use FAT? The linked article does not mention FAT anywhere. Besides FAT is just not a good choice. Other file systems like reiserfs have been carefully designed to avoid the slack problem being described here. Of course it could easilly have been avoided by not storing all data in a bunch of small files.
Just about anything would have been better than FAT. The minix file system is simpler and more efficient, but it doesn't help on slack. Reiser is more complicated, but does solve the slack problem. I don't know if they really need any journaling. It is quite easy to come up with a file system, that is better than FAT, and even one that is simpler and solve the slack problem. It is builtin, and there doesn't seem to be any need for compatibility with anything else.
Has everyone already forgotten about Internet 2?!?
Did you actually read what that page says before posting the link?
It does not aim to create a new network separate from the Internet but to ensure that new applications and technologies are deployed to the existing Internet.
The term "TCP/IP" is used to speak about all "the TCP/IP protocol
suite"
I did say "almost everybody", and this book might be on of the cases where the term is being used by somebody who know what he is talking about. But even in that case I consider it to be an inaccurate term. Because TCP is not common to all of the protocols, though some of them are built on top of TCP. Calling it "the UDP/IP protocol suite" would be just as correct/incorrect.
Calling it "the IP protocol suite" would be more accurate as they are all build directly or indirectly on top of IP. Of course the book might mention protocols like ARP, which is strictly speaking not built on top of IP. But since it is a protocol specifically designed to support IP over ethernet it would still make sense. I don't know if we can come up with an even more accurate term, maybe "the Internet protocols suite", but then we would get confusion between internet protocol and internet protocols.
If people would just stop talking about things they don't understand, things would get a lot more quiet. First of all almost everybody who use the term TCP/IP don't know what they are talking about. Because if they knew what they were talking about, they would use the right term, which is often one of the protocols IP, ICMP, UDP, or TCP.
Packet forwarding have nothing to do with TCP. It happens in the IP layer, the efficiency is obviously also to some extent affected by the lower layer protocols. But not the higher layers like TCP. But mostly efficiency of forwarding is an implementation issue, and not a property of the actual protocol.
To make things even worse a new term was invented to confuse people, and it is also called IP. Since this term covers a nonexisting concept it is in our best interrest not to use it. IP means Internet Protocol, any other use of that abreviation should be avoided. Unfortunately a lot people errornously use the term TCP/IP about the Internet Protocol.
Some confusion can be avoided by actually specifying the version number as well and say IPv4 or IPv6 rather than just IP. But for god's sake, make sure you use the right terms, or you will just cause even more confusion.
until ATI pulls their heads out of their asses and make linux binary drivers on par with nvidia they will continue to suck.
A binary only driver will always suck. But actually I have a computer with a Radeon 7000 that Fedora Core could use "out of the box". Some of their Mobility ones OTOH are going to cause lots of trouble. In fact I get better performance with a celeron 568 MHz CPU and i810 than on a 2.2GHz P4 laptop with a Radeon Mobility chip.
What I want to know about this laptop is if it works with all open source software, if not their certification is bullshit.
Slashdot Mirror
if the values in the array are distributed randomly
That doesn't matter. The analysis never said anything about the distribution of the numbers in the array. You may assume a worst case distribution of the numbers in the array, and the algorithm still works. Probability is meassured over random choices made by the algorithm, not over inputs. So given an input, you can compute the probability that the algorithm fails, which is always going to be a small number. Then you take the input giving the highest error probability (and now we are no longer assuming random choices, but deterministically chosing the worst case input). Since all the probabilities are small, even the largest of them will be small. This way of analysing error probabilities shouldn't come as a surprise, because that is how it is always done when considering probalistic algorithms.
Does updating the GPL to reflect the current address of FSF count as a revision?
Both Intel and AMD have stated that they plan to add virtualization support to forthcoming CPUs... Xen will be able to support unmodified guest operating systems
I have read about those plans. Still I wonder how well the virtualization will work. So maybe they will be able to virtualize a CPU we know today, but will they also be able to virtualize themselves? If the new CPU cannot virtualize itself it won't be long before we see a new Windows version requiring the virtualization features, such that this new Windows version will run only directly on the hardware and not in the virtual environment. If that happens we will back in todays state. Unless it will be able to virtualize itself, I don't trust all the promises about what good it will do.
This was going on when I was in high school, 10 years ago.
I also heard about this stuff when I was in high school 10 years ago. Some of my friends had TI-85 calculators, but I don't think any of them actually ever overclocked it.
The real joy was in installing a hacked ROM through an overflow on the link cable and running games written in Z80 assembly.
I tried some of those. But it wasn't really about hacking the ROM. The ROM was never changed, and if you removed the batteries it would still be restored to its original state. Also the way the assembler programs were transfered to the calculator was not through an overflow, but rather through a backup feature the calculator had. These calculators had a link cable, and one of the usages for this link cable was to create a full backup of the RAM. This full backup could either be stored on a PC using a special link cable or transfered to another calculator using the standard link cable. Transfering such a backup to a calculator would overwrite anything already in the RAM.
Now the trick was to create a backup on your PC and manipulate it there before transfering it back to the calculator. Inserting ASM code was the easy part, AFAIR it would all be put inside string variables which the standard software allowed you to manipulate. Actually executing this ASM code was the neat trick. This calulator had too many functions to make all directly available, for that reason it had a custom menu where you could put five of those for quick access. Now this was implemented using a pointer to the actual code in ROM for the selected function. In the manipulated backup one of this pointers would be altered to point into RAM rather than into ROM.
Once the backup image was ready it could be transfered to a calculator. The only way to insall this software on the calculator was through a full restore. But that could even be transfered from one calculator to another. Once you had the basic menusystem to access the ASM programs, you could transfer individual programs between calculators using standard features in the ROM. One drawback of using those ASM programs was, that while they were running the calculator wouldn't automatically turn off after some minutes of idle time, so you could easilly run down the batteries and would then need to start from scratch.
Obviously with daily backups there will be a lot of identical blocks. That is what I use in my software, every block written to the storage is compared against the existing data, and it is only written if it does not already exist. That way I get rid of large amounts of redundancy, and I just need to create some indexes to be able to reconstruct the original files. The most tricky part is how to find the existing blocks efficiently. The second tricky part is how to eliminate redundancy in the indexes. I think I'm doing quite well in both respects.
Currently I have 404GB of tar files in my storage, however the size of the storage is only 5.5GB. But the best part is, that this blocking is not only good for storing tar files, it also works very well with the Linux file system model. With a very simple driver based on block mapping, I can mount my storage as a file system and access all the tar files directly. I can even mount those tar files using tarfs (though tarfs still seems to be lacking a few important features). There is still a few things I need to change before I'm completely satisfied with my storage format. As soon as I don't see anymore reasons to change it, I will release it under GPL.
It is nigh-on impractical to guarantee that there has been no deviation or differnence between preproduction / staging envrionment and the live production environment which would cause problems like that.
There is an easy approach, which should work. Before doing your test you restore from the latest backup of your production system. Then you are reasonably sure the systems match, and at the same time you also have frequent testing of backup and recovery procedure.
Just curious, but why not change the old function to simply eliminate the problem
Probably that wasn't possible. The semaphore implementation in Linux is not trivial. First of all it have a fast path implemented in assembler, which is only a two instructions long. But that come with the cost of a very complicated implementation in case of contention. This give a good overall performance. But it may happen, that the caller of down continue while the up call is still accessing the semaphore. This is not a problem because you can still not make more down calls than up calls. However if the semaphore is removed from memory, you will have trouble with any up or down call not yet finished accessing the semaphore.
This is why completions were introduced. Completions are slightly simpler than semaphores, but the performance is worse. So completions should only be used where necesarry. In fact every access to the completion is protected by a spinlock. This means that even if there is not contention on the completion, there may be contention on the spinlock. Two concurrent up calls on a semaphore will both take the fast path, as long as they don't need to wakeup another process. However with completions, there is only a slow path.
or even just simply be an alias of the new function?
In the up_and_exit vs complete_and_exit case, that wouldn't have been possible, since they take different kinds of arguments. The up call takes a semaphore as argument, the complete call takes a completion as argument.
I could only assume the new function needed data not suplied in calls to the old function.
Kind of... you pass it a different data structure.
I don't know if a completion can do everything a semaphore can do. Maybe you would have gotten working code by using completions in every place where a semaphore was previously used. If that had worked, the fix could have been made without breaking compatibility. But it would come with a major performance penalty. It is not acceptable to introduce a huge overhead on thousands of semaphore users simply because a few rare cases have additional requirements. And you can't really seperate those needing completions from the rest without modifying the source code and recompiling it.
kernel developers intentionally and frequently break API/ABI compatibility between minor releases so as to "encourage" vendors to release drivers under non-proprietary licenses.
People keep saying that, but I have yet to see just a single case where it happened. Kernel interfaces do change, and they change for the better. But I have never seen a change, which happened just to encourage rease of driver sources.
Right now I can remember a single change between minor releases, somewhere in the 2.4 kernels the up_and_exit function was removed, and a new complete_and_exit was introduced. I don't know how many drivers where affected by that, but at least the USB driver had to be changed. Of course the change didn't happen to break compatibility. The purpose of up_and_exit was to avoid a race condition when removing a module which had a kernel thread running that needed to be stopped before removing the module. If the module had just called up to signal it was terminated, and afterwards called exit, the module code might have been removed before the up call returned and caused a kernel crash as it returned to an undefined address. Having the up_and_exit function solved that problem. But it turned out there was still a race condition. Though no code was accessed inside the module, the sempahore itself would be a part of the module, and it could be removed before up had finished accessing it. This is why completions were introduced, they are different from semaphores, and are designed exactly to avoid this problem. So every user of up_and_exit had to be changed to use complete_and_exit instead. Nothing would have prevented leaving up_and_exit in the kernel, but any user was known to have a race condition. Had the function been left in the kernel, a lot of those buggy users of it might not have been noticed. By removing up_and_exit all instances of the bug would be revealed, and could easilly be fixed.
This was just one example, there might be more. The point here, is that the change did not happen to intentionally break binary compatibility. The change happened to fix a problem. And while you might think it broke the compatibility, it really just revealed all the modules, that were already broken. And kernel developers frequently make changes to make debuging easier, that is part of the reason the code is of such a good quality.
The kernel developers don't intentionally break binary only modules, in fact it seems they ignore binary drivers as much as possible. If a change can improve the kernel, it happens. In stable branches such changes only happen if they are necesarry to fix a bug, or if they don't cause major breaking. If all drivers in the kernel can trivially be updated to the new interface, there is no reason not to make the change.
Does ISPs get sued because they have had child porn in the buffers on their routers? The freenet caches are no different. It is a different media and it is slower. But in both cases it is just a temporary storage for some information you are transfering between two parties, who you are not affiliated with.
The same thing could be done on a system running from a HD. Of course you have to pay attention to swap and temporary files, but it is not anymore difficult to do from a HD than from a CD. And the HD version is going to be faster than the CD version. But I guess Knoppix already supports this.
What would be even more interesting is the possibility to run untrackable stuff like that in parallel with a system that does fully use HD. Of course specifying who is allowed to use swap is the tricky part. Temporary files could be taken care of just by running the stuff in a chroot with no disk based file system mounted read-write.
The classic virus modified EXEs on disk, but didn't need to modify executable code in memory.
You are absolutely right. And that is why NX doesn't help preventing vira. It may prevent most classical worms though. Whether worms will find a way arround the protection is an open question. In theory the bugs may still be exploitable, but hopefully it will take longer time to write exploit code, so there will at least be time to patch your system. Protecting against vira modifying executables is easy, and it doesn't require the NX bit. You just have to ensure that you run all non-trusted programs under a user, that does not have write access to your executables.
SP2 adds NX "protection." While this adds protection against buffer overflows on the stack, it does nothing for overflows on the heap,
In Linux it is easier to use NX to protect the heap than to use NX to protect the stack. That is because on the heap, every allocation is explicitly marked executable or not executable. On the stack OTOH you don't have any way to know, if a particular page needs to be executable or not. Not all applications needs an executable stack, but gcc used to use the stack for trampolines, when you had a pointer to a nested function. Unless you can document, why it should be the other way arround in Windows, I don't believe it.
which can be just as bad.
It usually takes more work to exploit an overflow in the heap than in the stack, but as soon as working exploit code have been written, they are equally bad.
Also, if the return address is simply changed to an address on the heap, code in the heap can be executed.
Only if the heap is executable. You might find a usable function in the executable or a library, but you still need to pass arguments to really exploit it.
The heap has the executable bit, because of dynamic libraries loaded into the heap.
This is just plain wrong. The NX bit is about per page protection. Protecting an entire segment was always possible, it is just not usable in most cases.
Sad to say, but no matter how much you want to see that headline, it is not going to happen in 2005. A new and more secure Windows is something you might see in the headlines, however if that happens expect another headline when it gets hit by a nasty worm.
Maybe that could be a solution, use a sub domain as the actual mail address, and just prepend abuse@ as the address
I tried that, and it may help a bit, but you will still get spam. I tried exposing kasperd@ and abuse@ on the same domain equally much in my signature. In half a year 67 spam mails were sent to kasperd, 1 were sent to abuse, and 30 were sent to use. (Don't know how they got that idea). Anyway, it seems the address was not exposed enough.
On another domain the abuse address was used as from address in 151 usenet postings in the time from june 5th 2004 until the july 4th 2004. So far I have received 455 spam mails on the abuse address, and 5 spam mails sent to the Message-ID of some of my postings.
If you do, then Slashdot will become liable as they'll be linking to a site that links to copyright materials.
Don't laugh. Here in Denmark APG (the equivalent of RIAA or something like that) threatened to sue a man for a song that could be downloaded just eight links away from his page.
That sounds to be like a really inefficient form of greylisting.
It sure does. A greylistning is a better approach. And with greylistning you lose no legitimate emails (unless the sender use a seriously broken mail server). Before greylistning was introduced on our mail server approximately 90% of all incoming mail was removed by spamassassin. And that is even with a very high threshold, so a lot of spam still made it past the filter.
Once greylistning was introduced the amount of incoming mail dropped by a factor of about ten. And those are still filtered by spamassassin, though only 40% are filtered and 60% let through. In total that means 90% stopped by greylistning, 4% blocked by spamassassin, and 6% let through. And in my experience about half of those let through both filters are spam. I don't want to think about what my Inbox would look like without spam filtering.
If you can give someone a good bright flash before the one with which the picture is taken, that will contract their pupils and you won't see "red-eye".
Try that on me, and you will not be able to see what color the eyes have.
notice what the girl has written on the whiteboard: "Hacked by reallocl"
I think it says: "hacked by realloc(". I wonder what the original looked like. Was the girl also in the original? I can't find it anywhere (maybe sco can't either).
so I can take something compiled for a 2.4 kernel and it will run on a box still running a 1.0 kernel?
First of all you don't compile programs for a specific kernel. Most programs doesn't even call the kernel directly, but does so only through libraries. Assuming you have libraries and programs designed for 2.4, would you expect them to work on 1.0? I wouldn't. A lot of features have been added since then, your program is most likely going to use some of those. Besides 1.0 is really obsolete by now. I think you will have a very hard time finding a production system using anything older than 1.3.
But consider the other way around. Take a program and libraries written for the 1.3 kernel, I think there is a good chance it will work on 2.6. As long as it just use ordinary posix calls, I don't see what could go wrong. And you are not going to use anything else anyway, right? You do want your program to work on other posix systems as well. I have a program on my system which is available only in binary form. I have used that program since kernel version 2.2, and the same executable still works on 2.6.
Who says they use FAT? The linked article does not mention FAT anywhere. Besides FAT is just not a good choice. Other file systems like reiserfs have been carefully designed to avoid the slack problem being described here. Of course it could easilly have been avoided by not storing all data in a bunch of small files.
Just about anything would have been better than FAT. The minix file system is simpler and more efficient, but it doesn't help on slack. Reiser is more complicated, but does solve the slack problem. I don't know if they really need any journaling. It is quite easy to come up with a file system, that is better than FAT, and even one that is simpler and solve the slack problem. It is builtin, and there doesn't seem to be any need for compatibility with anything else.
Did you actually read what that page says before posting the link?
The term "TCP/IP" is used to speak about all "the TCP/IP protocol suite"
I did say "almost everybody", and this book might be on of the cases where the term is being used by somebody who know what he is talking about. But even in that case I consider it to be an inaccurate term. Because TCP is not common to all of the protocols, though some of them are built on top of TCP. Calling it "the UDP/IP protocol suite" would be just as correct/incorrect.
Calling it "the IP protocol suite" would be more accurate as they are all build directly or indirectly on top of IP. Of course the book might mention protocols like ARP, which is strictly speaking not built on top of IP. But since it is a protocol specifically designed to support IP over ethernet it would still make sense. I don't know if we can come up with an even more accurate term, maybe "the Internet protocols suite", but then we would get confusion between internet protocol and internet protocols.
Do you hear voices while you are reading posts online?
Sometimes
Do they all sound like little children?
No, only half of them.
If people would just stop talking about things they don't understand, things would get a lot more quiet. First of all almost everybody who use the term TCP/IP don't know what they are talking about. Because if they knew what they were talking about, they would use the right term, which is often one of the protocols IP, ICMP, UDP, or TCP.
Packet forwarding have nothing to do with TCP. It happens in the IP layer, the efficiency is obviously also to some extent affected by the lower layer protocols. But not the higher layers like TCP. But mostly efficiency of forwarding is an implementation issue, and not a property of the actual protocol.
To make things even worse a new term was invented to confuse people, and it is also called IP. Since this term covers a nonexisting concept it is in our best interrest not to use it. IP means Internet Protocol, any other use of that abreviation should be avoided. Unfortunately a lot people errornously use the term TCP/IP about the Internet Protocol.
Some confusion can be avoided by actually specifying the version number as well and say IPv4 or IPv6 rather than just IP. But for god's sake, make sure you use the right terms, or you will just cause even more confusion.
until ATI pulls their heads out of their asses and make linux binary drivers on par with nvidia they will continue to suck.
A binary only driver will always suck. But actually I have a computer with a Radeon 7000 that Fedora Core could use "out of the box". Some of their Mobility ones OTOH are going to cause lots of trouble. In fact I get better performance with a celeron 568 MHz CPU and i810 than on a 2.2GHz P4 laptop with a Radeon Mobility chip.
What I want to know about this laptop is if it works with all open source software, if not their certification is bullshit.