You are wrong, other distributions do have this problem. One of the comments gave a list of distributions all suffereing from this problem. You ask what changed, that is explained on bugzilla. The kernel will tell applications about the geometry of the disk, and the partitioning tool will trust those informations and generate partition table entries accordingly. The way the kernel reports geometry was changed. Older kernels would read the partitiontable and if the partitiontable looked like being generated for a specific geometry, the kernel would report this. Apparently this guessing have been removed, and the kernel now reports the the geometry as reported by the BIOS or the disk itself. Windows is even worse. Windows will simply assume 255 heads, no matter what the BIOS, the disk, or the partition table tells it. No data are destroyed. People only lost data because they did some stupid things either with the installer or in an attempt to fix their broken Windows. One person specifically asked the installer to format his C partition. If he lost some data it is certainly not because of a bug. And judging from the bugzilla comments this Windows bug have been known for years. You would have had the same problem if you tried to dualboot DOS and Windows NT on one of those computers.
Having read every comment on bugzilla about
Bug 115980 it sounds to me like the bug most likely is in Windows. On some machines Windows will create an incorrect partition table. FC2 will correct the partition table, and Windows stops booting. But a few of the latest comments suggests that it might be a bit more complicated than that. Because the problem doesn't happen immediately at install, but first at the first boot of either Windows or Fedora. It is unclear which of the two trigger the problem at the first boot. It seems very few people are able to reproduce the problem, which means it is not easy to track down. Instead of whining anybody who has this problem should help finding the cause. And finally another article on lwn mentions that no data loss happens unless you start doing something stupid.
This is the bit I was unsure about; I thought that pages which had not been used for a while would be swapped out even if memory was plentiful.
Actually that doesn't make any difference. In some cases it would make sense to write pages to swap when they haven't been written to for a while, even if you have loads of free memory. But it only makes sense as long as you support having a copy of the page both on swap and in RAM. The point would be, that if you have a copy in each place, you can quickly discard one of the two, if you would ever need to. But removing the copy from RAM as long as you have free RAM would be stupid. And writing pages to swap if the disk is busy doing other work wouldn't be a good idea either (unless of course you are already out of RAM).
So whether there is a copy of the pages on swap or not, they will still take up a page of your fastest RAM. There is no need to remove them from RAM yet, because there is plenty of slow RAM free. (Remember the kernel doesn't know it is running on a broken computer where some of the RAM is slow). But I don't think Linux starts writing pages to swap before it needs to.
Not using cache for the uppermost 64MB on a 128MB system essentially means the uppermost 64MB will be slower. So does the allocation work bottom up or top down? I actually don't know. But that only matters in the begining. When the system has been running for a long time memory is so fragmented that you are essentially using random parts of your memory.
When you boot a 64MB system and finally have X running, some pages will probably already be swapped out. But many of those you are probably never going to need. So while it did slow down the boot a bit, the performance of the system is fine. If you add 64MB of memory to this system, and those 64MB are slower, what could happen is, that no pages are swapped out. So those pages you don't need are now in your fast memory instead of on the swap partition. The pages you really need get some slow pages instead.
So the kernel thinks nothing is wrong, because it doesn't know some of the RAM is slow. But in reallity half of your memory accesses will have to go to RAM insted of cache. So whenever you should have had two cache hits, you now get one expensive RAM access. So assuming the RAM is ten times as slow as the cache (not unrealistic), the slowdown would be a factor of five.
I never had one of those computers myself, so I don't have any meassurements to backup the theory. Luckily my computers always got faster when I added more RAM.
Actually the limit is 3GB per process because one GB is used for the kernel. That means that even if one process goes wild and allocates the maximum of 3GB, and then forks, my 6GB of swap will still be enough. (Not that it ever happened to me).
Rememeber the Great VM Replacement in 2.4.10?
I remember hearing about it, but I don't think I ever noticed a difference.
Or the current mess with reverse mapping?
AFAIK the performance is fine, the worst problem is the amount of memory it consumes for management. But Andrea Arcangeli has a solution.
I think you're confusing virtual and physical memory.
No I'm not. You are confusing kernel space and user space. Kernel space allocations have to be contiguous in both physical and virtual address space.
Re:If You have enough RAM
on
Is Swap Necessary?
·
· Score: 2, Interesting
True fragmentation of memory does not mean performance decrease. But fragmentation can still be a problem in some cases. For example if you need to allocate multiple pages at once, and only have scateret single pages available, the allocation would either fail, or you would have to free some memory. This is one of the reasons the task struct + stack allocation in Linux have finally been reduced from two to just one page (on x86 that is, I don't know about other architectures).
Another possibility, that has been suggested for 2.7 is defragmentation of memory. Of course just because it has been suggested doesn't mean it is going to happen. Without defragmentation, what are your options to satisfy a larger allocation in case of fragmented memory? You'd have to free some memory, either by reducing the disk cache size, swapping out anonymous pages, or find some slabs that can be freed. But notice that with more memory there would be more possible choices for what to free, so it would have a better chance of picking something you won't need in the near future. If you used some ram for a ramdisk for swap, then you should not expect to use all of that ram. So effectively you are using less of your memory, which again could mean smaller chance of finding what you need in RAM. The failing allocation might as well be satisfied by removing a page from the page cache, which is certainly less disirable.
Of the given suggestions defragmentation of memory is probably the only that shouldn't cause performance problems in specific corner cases. (Me thinking back on the good ol' days with MS DOS and AmigaOS where the only solution to memory fragmentation was a reboot).
if I have say 3 Gigs of RAM, do I really NEED 6 Gigs of swap?
Maybe you don't need it. But it doesn't hurt either. Disk space is cheap. I configure my computers with lots of swap space just in case. I have often allocated 6GB for swap on computers with a lot less RAM than you have. I have one computer with 256MB of RAM and three harddisks. I have a 2GB swap partition on each harddisk. (The rest of the disk space is used for a raid-1 system partition and a raid-5 data partition.)
Re:Where many people miss the point...
on
Is Swap Necessary?
·
· Score: 2, Interesting
Yes, it is swappnig because it is trying to free up "low memory", of which you have less that a gig.
Actually this sounds likely, but is it a good idea? Alternatively it could do a memcpy of your data from low memory to high memory. So now you have the choice between occupying the CPU to perform the memcpy, or occupying the disk controller to swap it out. But data that you could swap out is process memory, which you'd expect to be allocated from the high memory. So how do you actually reach a situation where process memory pages end up in low memory? You'd have to fill up the high memory first. Of course if you run a program that requires a lot of memory, which is all allocated from high memory, then other programs might get low memory. When the first program terminates you could have a lot of free high memory and other programs still taking up the low memory.
Re:If You have enough RAM
on
Is Swap Necessary?
·
· Score: 2, Insightful
Alternatively, under what kind of running application mix is it true that reserving Y amount for swap yields a better memory management algorithm than using X+Y fully?
I don't think you will find an application where that is the case. But maybe if the Y amount you allocate for swap happened to be slower than the rest of the RAM, it could improve performance. If all of your RAM has the same speed, the VM really have to be f***ed up to not give you better performance when it can manage all of your RAM.
I don't have to compare them to tell you what result you should
expect.
256MB ram without swap is the fastest of the three you mention. 128MB ram and 128MB swap is the slowest. And 128MB ram and a 128MB ramdisk used as swap is somewhere between the two (probably closest to the 256MB of RAM). So taking a part of your RAM and using it as swap should slow down your system. If it actually increases performance, it doesn't indicate that it is a good idea, it just indicates you found a bug in the VM. If you can actually demonstrate a bug causing a decreased performance when using all your RAM as RAM, I'm sure there are people who would like to know about it.
That is of course all assuming there is no difference in the speed of your RAM. If parts of your RAM have different speeds, it is an interely different story. It might improve performance to use the fastest parts of RAM as real RAM, and use the slowest parts of RAM as a ramdisk that you swap to. But it would be even better if the VM knew about the differences and could use the slow parts of RAM for more than just swap, but still keep the most used stuff in the fast parts of RAM.
I have heard about cases, where a machine became slower by upgrading it from 64MB of RAM to 128MB of RAM, because the cache could only be used for the lower 64MB of RAM.
So he found a similarity in ctype.h. Of course that could not have been stolen from Minix. It was stolen from SCO. Unless there is another explanation for the similarities.
The submission of patches is supposed to continue like it has always done. It is all about two things, people passing the patch on putting their name on it, so you can see the path. And certifying that you are allowed to submit the patch, which you were already implicitly stating by submiting it. The orignial message is on the mailing list. The media have blown this news up completely out of proportion. If just the media had something like this we could track who made this feather into five chickens. I doubt all the media covering this, actually read what Linus wrote.
What if someone uses Linux in a 'mission critial' situation and it fails due to a bug?
How would that ever make individual developers liable? The developer did not build the mission critical system. And the developer did not intend his code to be used in that way. If you are liable for anything you made being used by somebody in a way it was not intended to be used, there is no end to liability. What if somebody connected a lot of rubber bands and used it for bungee jumping. Would the rubber band manufacturer be liable?
Two drives on same IDE channel is always going to be a performance problem if you intend to use both drives. If you are only going to use one of the drives it will not make much of a difference. Which is master and which is slave is not so important, when both are in use, both will take a performance hit. Having an error on one of the drives is the worst that can happen, the other drive will have to wait for the first to time out. My advise would be to buy an extra IDE controller. And don't be so afraid to change the fstab.
I'm most awake just after going to bed. In fact I'm so awake that I might just spend the first half of the night awake. Guess I don't need to tell when I'm most tired.
It had over 90% cpu usage too when I experienced the problem.
In that case it might be a different problem. Did you try using strace on the process? Actually I have seen netscape using 99% of the CPU time until a NNTP connection times out. Just goes like
or something like that all the time. Until eventually the connection times out. So it is possible. I don't know if that is what is happening with up2date. I don't use up2date myself, it is much more reliable to use wget to download the updates.
Call me nuts, but playing MP3's these days is about as basic as being able to copy a file from one place to another.
There are better alternatives to MP3. Of course that is not why MP3 support was removed. It was removed because of patents, and that happened already around RH7.3 IIRC. Since then I got MP3 and DVD playing programs from freshrpms. Looks like there are no FC2 packages there yet, but I believe they will come. Until then you could try the FC1 packages.
But what's with the no xfree86?
License changes. What you get instead is AFAIK a fork from just before the license change, so it is really the same software, just a new name.
I got a Linux distro working, the GUI was *slow as hell*.
Probably driver problems. Are you sure you are using the right hardware? I know some of the desktop environments have been bloated. But I think they have started caring about it. It is long time since the last time I felt the GUI had become slower from an update.
Within the hour, up2date would always suddenly resume and complete the update.
I have seen those, and even took the time to look into the reason. Of course it was a bit tricky, as it would sometimes resume before I had had enough time to find the reason. But I did manage to find out what was happening. It was simply waiting for a very slow HTTP server to reply. I think there are just too many people trying to download from download.fedora.redhat.com at the same time.
I really can't understand how they released it with such bug.
It is not a bug, it is a feature. Seriously, I don't have Windows on any of my computers. I don't care if I can boot Windows or not. There is a simple solution for the data loss you are talking about, it is called a backup. How could you even be sure the data loss was not just caused by user errors? So should it be released? Windows 95 AFAIK had some similar problems, that didn't stop Microsoft from releasing it. Right now there are a lot of bug reports, but no indication whatsoever, there really is a bug in Fedora Core 2. The specifically ask for somebody to try to reproduce the problem with Fedora Core 2, seems like it might happen only if there is already a problem with the partition table. There are a lot of worse issues. For example if you don't have at least a 686 machine, you shouldn't even try to install Fedora Core 1. There are bugs in glibc causing random crashes, and no attempt is done to fix them.
Maybe you are thinking about stack based buffer overflows. Stack based buffer overflows are often easy to exploit, and I think more than 50% of the worms on the internet use such exploits. It just means that you can overflow a buffer, which is allocated on the stack. When such an overflow happens, the return address is usually just a few bytes away, so you can change the return address to point into the buffer you just filled with code.
A stack overflow OTOH rarely happens, unless you trigger an infinite recursion in the code. Normally a stack overflow will just result in a DoS attack, because the OS will kill any process that overflows its stack. There should always be an unmapped page between the stack and any other mapping, such that overflows can be catched. (Could you overflow a kernel stack it would be an entirely different matter)
A heap overflow just means you overflow a buffer allocated from the heap. Any return address is far away, so they are not as trivial to exploit. But you can corrupt memory management data structures, which you might be able to use to have the memory management system return allocations overlapping with other important areas, which you might then be able to get overwritten. It can get very complicated. Take a look on Vudo - An object superstitiously believed to embody magical powers (Smashing The Heap For Fun And Profit)
the command prompt is just the equivalent of a shell.
Obviously you can't imagine what kind of a mess DOS really was. COMMAND.COM was not just a program running on top of the kernel. There actually was an undocumented system call, that would send a command line to be executed by the running instance of COMMAND.COM. I once tried writing a program to use that call and used it from within a.BAT file. The result was very interesting. IIRC the program would terminate allowing the.BAT file to continue, and the command would get executed when the.BAT file had terminated. But I even think that depended on which DOS version you used.
What kind of "design" can explain that behavioure? Of course it would work differently if you used a different shell. Multiple alternatives for COMMAND.COM existed, none of them were messing with the kernel in the same way though. COMMAND.COM was really tied to a particular kernel version unlike the alternatives.
The kernel contained a system call which you might consider as the equivalent of the readline library. COMMAND.COM actually didn't implement the very limited line editing on it's own. The system call did that. I once wrote a TSR program to replace the system call with a version with command line history and other goodies. Of course my TSR would fail if you started windows and opened two DOS windows because my code wasn't reentrant. I ended up just detecting if another instance was running and fall back to the original input routine in that case. I could have done better if I could have reliably allocated some memory. But memory management with DOS was a pain, and windows on top and DOS programs in those made everything worse. I would have believed two DOS windows would be seperated with each getting their own memory, but no. My TSR utility loaded before Windows was started would be shared, the BIOS data segment and interrupt vectors OTOH would not.
Actually using the underlying DOS for two DOS windows really doesn't seem like a good idea when the underlying system is inherently single tasking. You could argue that TSR programs was a bad idea to begin with, and I would agree with you, but sometimes they were the only way to do a specific task under DOS. And any normal DOS system would have at least a handful of those.
Imagine how much better the world would have been today if IBM had been willing to spend those extra 64KB of RAM it would have required to run a real UNIX instead of MSDOS.
Slashdot Mirror
All previos Linux distro's and windows LISTEN to the BIOS
Actually from what I have read about the problem it is the other way around. The problem really is that Windows does not respect what the bios says.
You are wrong, other distributions do have this problem. One of the comments gave a list of distributions all suffereing from this problem. You ask what changed, that is explained on bugzilla. The kernel will tell applications about the geometry of the disk, and the partitioning tool will trust those informations and generate partition table entries accordingly. The way the kernel reports geometry was changed. Older kernels would read the partitiontable and if the partitiontable looked like being generated for a specific geometry, the kernel would report this. Apparently this guessing have been removed, and the kernel now reports the the geometry as reported by the BIOS or the disk itself. Windows is even worse. Windows will simply assume 255 heads, no matter what the BIOS, the disk, or the partition table tells it. No data are destroyed. People only lost data because they did some stupid things either with the installer or in an attempt to fix their broken Windows. One person specifically asked the installer to format his C partition. If he lost some data it is certainly not because of a bug. And judging from the bugzilla comments this Windows bug have been known for years. You would have had the same problem if you tried to dualboot DOS and Windows NT on one of those computers.
Having read every comment on bugzilla about Bug 115980 it sounds to me like the bug most likely is in Windows. On some machines Windows will create an incorrect partition table. FC2 will correct the partition table, and Windows stops booting. But a few of the latest comments suggests that it might be a bit more complicated than that. Because the problem doesn't happen immediately at install, but first at the first boot of either Windows or Fedora. It is unclear which of the two trigger the problem at the first boot. It seems very few people are able to reproduce the problem, which means it is not easy to track down. Instead of whining anybody who has this problem should help finding the cause. And finally another article on lwn mentions that no data loss happens unless you start doing something stupid.
This is the bit I was unsure about; I thought that pages which had not been used for a while would be swapped out even if memory was plentiful.
Actually that doesn't make any difference. In some cases it would make sense to write pages to swap when they haven't been written to for a while, even if you have loads of free memory. But it only makes sense as long as you support having a copy of the page both on swap and in RAM. The point would be, that if you have a copy in each place, you can quickly discard one of the two, if you would ever need to. But removing the copy from RAM as long as you have free RAM would be stupid. And writing pages to swap if the disk is busy doing other work wouldn't be a good idea either (unless of course you are already out of RAM).
So whether there is a copy of the pages on swap or not, they will still take up a page of your fastest RAM. There is no need to remove them from RAM yet, because there is plenty of slow RAM free. (Remember the kernel doesn't know it is running on a broken computer where some of the RAM is slow). But I don't think Linux starts writing pages to swap before it needs to.
Not using cache for the uppermost 64MB on a 128MB system essentially means the uppermost 64MB will be slower. So does the allocation work bottom up or top down? I actually don't know. But that only matters in the begining. When the system has been running for a long time memory is so fragmented that you are essentially using random parts of your memory.
When you boot a 64MB system and finally have X running, some pages will probably already be swapped out. But many of those you are probably never going to need. So while it did slow down the boot a bit, the performance of the system is fine. If you add 64MB of memory to this system, and those 64MB are slower, what could happen is, that no pages are swapped out. So those pages you don't need are now in your fast memory instead of on the swap partition. The pages you really need get some slow pages instead.
So the kernel thinks nothing is wrong, because it doesn't know some of the RAM is slow. But in reallity half of your memory accesses will have to go to RAM insted of cache. So whenever you should have had two cache hits, you now get one expensive RAM access. So assuming the RAM is ten times as slow as the cache (not unrealistic), the slowdown would be a factor of five.
I never had one of those computers myself, so I don't have any meassurements to backup the theory. Luckily my computers always got faster when I added more RAM.
Actually the limit is 3GB per process because one GB is used for the kernel. That means that even if one process goes wild and allocates the maximum of 3GB, and then forks, my 6GB of swap will still be enough. (Not that it ever happened to me).
Rememeber the Great VM Replacement in 2.4.10?
I remember hearing about it, but I don't think I ever noticed a difference.
Or the current mess with reverse mapping?
AFAIK the performance is fine, the worst problem is the amount of memory it consumes for management. But Andrea Arcangeli has a solution.
I think you're confusing virtual and physical memory.
No I'm not. You are confusing kernel space and user space. Kernel space allocations have to be contiguous in both physical and virtual address space.
True fragmentation of memory does not mean performance decrease. But fragmentation can still be a problem in some cases. For example if you need to allocate multiple pages at once, and only have scateret single pages available, the allocation would either fail, or you would have to free some memory. This is one of the reasons the task struct + stack allocation in Linux have finally been reduced from two to just one page (on x86 that is, I don't know about other architectures).
Another possibility, that has been suggested for 2.7 is defragmentation of memory. Of course just because it has been suggested doesn't mean it is going to happen. Without defragmentation, what are your options to satisfy a larger allocation in case of fragmented memory? You'd have to free some memory, either by reducing the disk cache size, swapping out anonymous pages, or find some slabs that can be freed. But notice that with more memory there would be more possible choices for what to free, so it would have a better chance of picking something you won't need in the near future. If you used some ram for a ramdisk for swap, then you should not expect to use all of that ram. So effectively you are using less of your memory, which again could mean smaller chance of finding what you need in RAM. The failing allocation might as well be satisfied by removing a page from the page cache, which is certainly less disirable.
Of the given suggestions defragmentation of memory is probably the only that shouldn't cause performance problems in specific corner cases. (Me thinking back on the good ol' days with MS DOS and AmigaOS where the only solution to memory fragmentation was a reboot).
if I have say 3 Gigs of RAM, do I really NEED 6 Gigs of swap?
Maybe you don't need it. But it doesn't hurt either. Disk space is cheap. I configure my computers with lots of swap space just in case. I have often allocated 6GB for swap on computers with a lot less RAM than you have. I have one computer with 256MB of RAM and three harddisks. I have a 2GB swap partition on each harddisk. (The rest of the disk space is used for a raid-1 system partition and a raid-5 data partition.)
Yes, it is swappnig because it is trying to free up "low memory", of which you have less that a gig.
Actually this sounds likely, but is it a good idea? Alternatively it could do a memcpy of your data from low memory to high memory. So now you have the choice between occupying the CPU to perform the memcpy, or occupying the disk controller to swap it out. But data that you could swap out is process memory, which you'd expect to be allocated from the high memory. So how do you actually reach a situation where process memory pages end up in low memory? You'd have to fill up the high memory first. Of course if you run a program that requires a lot of memory, which is all allocated from high memory, then other programs might get low memory. When the first program terminates you could have a lot of free high memory and other programs still taking up the low memory.
Alternatively, under what kind of running application mix is it true that reserving Y amount for swap yields a better memory management algorithm than using X+Y fully?
I don't think you will find an application where that is the case. But maybe if the Y amount you allocate for swap happened to be slower than the rest of the RAM, it could improve performance. If all of your RAM has the same speed, the VM really have to be f***ed up to not give you better performance when it can manage all of your RAM.
I don't have to compare them to tell you what result you should expect.
256MB ram without swap is the fastest of the three you mention. 128MB ram and 128MB swap is the slowest. And 128MB ram and a 128MB ramdisk used as swap is somewhere between the two (probably closest to the 256MB of RAM). So taking a part of your RAM and using it as swap should slow down your system. If it actually increases performance, it doesn't indicate that it is a good idea, it just indicates you found a bug in the VM. If you can actually demonstrate a bug causing a decreased performance when using all your RAM as RAM, I'm sure there are people who would like to know about it.
That is of course all assuming there is no difference in the speed of your RAM. If parts of your RAM have different speeds, it is an interely different story. It might improve performance to use the fastest parts of RAM as real RAM, and use the slowest parts of RAM as a ramdisk that you swap to. But it would be even better if the VM knew about the differences and could use the slow parts of RAM for more than just swap, but still keep the most used stuff in the fast parts of RAM.
I have heard about cases, where a machine became slower by upgrading it from 64MB of RAM to 128MB of RAM, because the cache could only be used for the lower 64MB of RAM.
So he found a similarity in ctype.h. Of course that could not have been stolen from Minix. It was stolen from SCO. Unless there is another explanation for the similarities.
The submission of patches is supposed to continue like it has always done. It is all about two things, people passing the patch on putting their name on it, so you can see the path. And certifying that you are allowed to submit the patch, which you were already implicitly stating by submiting it. The orignial message is on the mailing list. The media have blown this news up completely out of proportion. If just the media had something like this we could track who made this feather into five chickens. I doubt all the media covering this, actually read what Linus wrote.
What if someone uses Linux in a 'mission critial' situation and it fails due to a bug?
How would that ever make individual developers liable? The developer did not build the mission critical system. And the developer did not intend his code to be used in that way. If you are liable for anything you made being used by somebody in a way it was not intended to be used, there is no end to liability. What if somebody connected a lot of rubber bands and used it for bungee jumping. Would the rubber band manufacturer be liable?
The list is even repeated on multiple newsgroups. Two of which are archived on google groups: fa.linux.kernel linux.kernel
Two drives on same IDE channel is always going to be a performance problem if you intend to use both drives. If you are only going to use one of the drives it will not make much of a difference. Which is master and which is slave is not so important, when both are in use, both will take a performance hit. Having an error on one of the drives is the worst that can happen, the other drive will have to wait for the first to time out. My advise would be to buy an extra IDE controller. And don't be so afraid to change the fstab.
I'm most awake just after going to bed. In fact I'm so awake that I might just spend the first half of the night awake. Guess I don't need to tell when I'm most tired.
In that case it might be a different problem. Did you try using strace on the process? Actually I have seen netscape using 99% of the CPU time until a NNTP connection times out. Just goes likeor something like that all the time. Until eventually the connection times out. So it is possible. I don't know if that is what is happening with up2date. I don't use up2date myself, it is much more reliable to use wget to download the updates.
Call me nuts, but playing MP3's these days is about as basic as being able to copy a file from one place to another.
There are better alternatives to MP3. Of course that is not why MP3 support was removed. It was removed because of patents, and that happened already around RH7.3 IIRC. Since then I got MP3 and DVD playing programs from freshrpms. Looks like there are no FC2 packages there yet, but I believe they will come. Until then you could try the FC1 packages.
But what's with the no xfree86?
License changes. What you get instead is AFAIK a fork from just before the license change, so it is really the same software, just a new name.
I got a Linux distro working, the GUI was *slow as hell*.
Probably driver problems. Are you sure you are using the right hardware? I know some of the desktop environments have been bloated. But I think they have started caring about it. It is long time since the last time I felt the GUI had become slower from an update.
Within the hour, up2date would always suddenly resume and complete the update.
I have seen those, and even took the time to look into the reason. Of course it was a bit tricky, as it would sometimes resume before I had had enough time to find the reason. But I did manage to find out what was happening. It was simply waiting for a very slow HTTP server to reply. I think there are just too many people trying to download from download.fedora.redhat.com at the same time.
I really can't understand how they released it with such bug.
It is not a bug, it is a feature. Seriously, I don't have Windows on any of my computers. I don't care if I can boot Windows or not. There is a simple solution for the data loss you are talking about, it is called a backup. How could you even be sure the data loss was not just caused by user errors? So should it be released? Windows 95 AFAIK had some similar problems, that didn't stop Microsoft from releasing it. Right now there are a lot of bug reports, but no indication whatsoever, there really is a bug in Fedora Core 2. The specifically ask for somebody to try to reproduce the problem with Fedora Core 2, seems like it might happen only if there is already a problem with the partition table. There are a lot of worse issues. For example if you don't have at least a 686 machine, you shouldn't even try to install Fedora Core 1. There are bugs in glibc causing random crashes, and no attempt is done to fix them.
I'm familiar with stack overflows.
Maybe you are thinking about stack based buffer overflows. Stack based buffer overflows are often easy to exploit, and I think more than 50% of the worms on the internet use such exploits. It just means that you can overflow a buffer, which is allocated on the stack. When such an overflow happens, the return address is usually just a few bytes away, so you can change the return address to point into the buffer you just filled with code.
A stack overflow OTOH rarely happens, unless you trigger an infinite recursion in the code. Normally a stack overflow will just result in a DoS attack, because the OS will kill any process that overflows its stack. There should always be an unmapped page between the stack and any other mapping, such that overflows can be catched. (Could you overflow a kernel stack it would be an entirely different matter)
A heap overflow just means you overflow a buffer allocated from the heap. Any return address is far away, so they are not as trivial to exploit. But you can corrupt memory management data structures, which you might be able to use to have the memory management system return allocations overlapping with other important areas, which you might then be able to get overwritten. It can get very complicated. Take a look on Vudo - An object superstitiously believed to embody magical powers (Smashing The Heap For Fun And Profit)
the command prompt is just the equivalent of a shell.
.BAT file. The result was very interesting. IIRC the program would terminate allowing the .BAT file to continue, and the command would get executed when the .BAT file had terminated. But I even think that depended on which DOS version you used.
Obviously you can't imagine what kind of a mess DOS really was. COMMAND.COM was not just a program running on top of the kernel. There actually was an undocumented system call, that would send a command line to be executed by the running instance of COMMAND.COM. I once tried writing a program to use that call and used it from within a
What kind of "design" can explain that behavioure? Of course it would work differently if you used a different shell. Multiple alternatives for COMMAND.COM existed, none of them were messing with the kernel in the same way though. COMMAND.COM was really tied to a particular kernel version unlike the alternatives.
The kernel contained a system call which you might consider as the equivalent of the readline library. COMMAND.COM actually didn't implement the very limited line editing on it's own. The system call did that. I once wrote a TSR program to replace the system call with a version with command line history and other goodies. Of course my TSR would fail if you started windows and opened two DOS windows because my code wasn't reentrant. I ended up just detecting if another instance was running and fall back to the original input routine in that case. I could have done better if I could have reliably allocated some memory. But memory management with DOS was a pain, and windows on top and DOS programs in those made everything worse. I would have believed two DOS windows would be seperated with each getting their own memory, but no. My TSR utility loaded before Windows was started would be shared, the BIOS data segment and interrupt vectors OTOH would not.
Actually using the underlying DOS for two DOS windows really doesn't seem like a good idea when the underlying system is inherently single tasking. You could argue that TSR programs was a bad idea to begin with, and I would agree with you, but sometimes they were the only way to do a specific task under DOS. And any normal DOS system would have at least a handful of those.
Imagine how much better the world would have been today if IBM had been willing to spend those extra 64KB of RAM it would have required to run a real UNIX instead of MSDOS.