Is GCC not supported on a 286? I think as long as you could run almost ANY operating system you can run GCC.
I have used gcc under DOS 6.20 on a 486. It was not particularily fast and did use protected mode. I know the 286 has protected mode, but I think gcc uses 32 bit code, which is not an option on the 286. It came with some runtime environment to setup protected mode and even included virtual memory. I later found the same virtual memory could help when running MCAFEE on a computer with only 4MB of RAM. It was implementing some standard whose name I don't recall.
IIRC 2.4.20 has one as well. Vendor kernels are (should be) patched against it. But if you wanted a nonexploitable kernel from kernel.org you'd have to use a prerelease. Nobody wanted to rush 2.4.21 through because of that particular bug.
you should see "swapper" (or something similar) floating around in there.
On Linux "swapper" is usually the idle thread that gets the CPU when nobody else needs it. That process basically runs an infinite loop calling the HLT instruction. I think it is the "kswapd" process you had in mind. Cases have been seen where kswapd would use a lot of CPU time. I'm not sure it was caused by the harddisk drive. AFAIK it happened under high memory pressure. It might even be that more swap available would have speeded up kswapd. If you really have a lot of CPU usage in your harddisk driver, you should see larger system percentages caused by other processes accessing the disk.
Even when it was done creating the thumbnails, it still ate up CPU and ram.
I never experienced that problem. Could be you have run into some weird KDE bug rather than just a bloated feature. Personally I like having those thumbnails created. As long as you don't have to wait for it to complete before proceeding with your work, and it stops when you close the window, I don't see a problem.
If I am using under x percentage of physical RAM, my system doesn't touch swap. At all.
Under Linux I don't think any swap will be used before you get low on physical memory. I think you might be able to push the usage as high as 95% before swap is being used. The algorithms used in Linux are not perfect, but quite good. It should be possible to have the same page in physical RAM and on swap at the same time, I don't think Linux can do that. The advantage is that you can write a lot of pages to swap long time before you really need the memory. Then you can reuse the physical memory quicker than you could have done if you first started writing when you actually needed the memory. Of course premature writing to swap should only happen if the disk is otherwise idle and has not been idle long enough to cause a spin down.
Perhaps our Danish Slashdotters could fill us in about the organizations who funded this study.
The Danish "newspaper" Computerworld had an
article about it. But unfortunately it is not completely clear who is behind the study. It says "Arbejdsskadestyrelsen og ankeinstansen" (agency of industrial injury and the appeal tribunal) will be using the results to judge whether the damages can qualify as industrial injury. It also states that head of the study consultant Johan Hviid Andersen at Herning central hospital has pointed out that it is too early to completely rule out, that mice can cause damages. And he still advices people working at the screen at least 20-25 hours a week to take care of themselves and take many small breaks during the working day. The final report is expected to be finished by October.
What is the processor spending its time on? wait() for the storage to catch up?
You cannot easilly tell. At least top is not going to help you there.
playing with swap?
CPU playing with swap? It doesn't, it starts the controller, and then go doing something else until an interrupt arrives from the controller. Sure if you don't enable DMA the CPU does have to spend a lot of CPU time in the driver, but usually you will spot the higher system percentage in top if that is the case.
handling interrupt requests?
Unfortunately top does not tell me how much CPU time is spend handling interrupt requests. But interrupt requests are not supposed to use more than a few cycles of CPU time. If more time is needed the code should be executed in some other context scheduled by the interrupt.
creating fucking thumbnails?
If you want thumbnails of your pron collection, you will expect fucking thumbnails won't you?
The CPU is rarely the bottleneck. 9/10 its the storeage, then the network.
True, and that is obvious from the output of top.
make sure you don't hit swap (I have swap for the sole purpose of a kernel dump after a panic. 1xRAM + 30M to make sure there is enough space.)
Too litle swap can slow down your system. To most people it is not obvious, but swap does give the system the oportunity to swap out unused data, so the physical memory can be used for something better. Though I don't always agree with my kernels decissions on what is the best way to use my physical memory. Finally more swap can sometimes avoid those nasty consequences from the kernel overcommiting memory.
Back when it took Intel a long time to come out with a new CPU architecture or speed boost, programs would see tremendous performance boosts between versions as the programmers would have time to optimise to the *existing* hardware.
I recently heard something interesting about the game hitman 2. The first version was not available for PS2, but the new version is. They had to do a lot of performance tweaking because of the slow CPU and small amount of memory in the PS2. The end result actually was that even the PC version because of those code improvements does not require more computing power than the previous version (except from on the graphics board).
and wait a minute for the characters to agonizingly appear one at a time on the screen.
I tried different emulators on an A1200. And as long as you were just typing simple DOS commands the speed was acceptable. At least one of the emulators came with a native ANSI.SYS driver, that could speed up text output significantly. If you forgot to use such a thing, I can imagine it must have been slow.
Collisions is not caused by driver problems. The way ethernet was designed simply means collisions cannot be avoided. The work done to limit the amount of collisions as much as possible is best done in hardware. If anybody was stupid enough to make hardware requiring those features to be in the driver, the hardware designers are to blame, not the driver designers.
But then again such a license agreement could be a violation of the copyright law. In the country where I live, the law explicitly says the user has the right to decompile if that is the only way to find the necesarry information to make a program you are developing interoperable. And the law says that right cannot be given up by agreement.
Counterfitters won't even try to adjust to the new bills if the old ones are still in circulation and legal tender - there's just no reason to.
I have always been wondering why they don't counterfeit the new ones which people are not so familiar with. Being unfamiliar with it, you should have a harder time realizing it was fake.
I have a lot more experience with the filesystem layout than that.
What makes you think they have not done this?
The information telling us that the seperation of/,/usr, and/usr/local was discarded. If you really think they did such a great job, then why do you think they did not document it?
I don't see why you think the filesystem is a mess. There are a few essential locations you should know the purpose of, and then it is all very intuitive. I have seen Unix systems worse than that. Why does anybody want to put ping in etc?
Oooo, this bit of SysV is shiny!
SysV initscripts is a mess, but that doesn't make the entire filesystem a mess./sbin/init and/etc/inittab is quite simple and really not any kind of mess, but all those rc scripts thrown on top is a mess. What I'd do is to add a few small features to/sbin/init and then get rid of all those rc scripts.
Next thing they'll probably by popping all of the/sbin tools in/bin...
That wouldn't be the worst thing they could do. Many of the executables in/sbin I often use as non-root user, so I simply need/sbin in my path anyway. So the only good reason remaining for different directories is the few executables in/usr/bin which are really a suid wrapper prompting for a root password before executing the real program in/usr/sbin. But those can be implemented in other ways.
I really liked the idea of reorganising directory structure.
Don't make reorganisations without a purpose. The current orginaisation might not be perfect. But to me it sounds like the change they made introduces new problems without solving any of the existing problems. Though I have installed a distribution taking up more than 3GB of disk space, less than 300MB of that is in the / filesystem. And in fact it was only/usr and/home I located on seperate partitions. This means I could backup my / partition on a bootable CD if I wanted to. With their reorganisation I don't think there is an easy way to split files into important files that need to be on / and less important files, that can be on a larger readonly filesystem which is not necesarry for the basic system maintainance tasks. Before reorganising you should identify the problems you want to solve, and you should understand why the system looks the way it does to avoid breaking the system. Finally you must ensure that your reorganisation in fact achieved the desired results.
Fully standards compliant mpeg4. It's not going to look nearly as good as XviD or DivX5, but it will be "durable."
When considering durablity the physical media format is much more important than the encoding format. If your physical media is durable any encoding will be durable. Actually finding a decoder is another issue, having decoder source on the media together with the movie improves the chances. When XviD or DivX is called less durable it is AFAIK because they are often recorded with less error correction on the physical media. If you have more error correction and allow yourself to spend two medias on each film rather than one, your chances of not loosing the data improve. If you finally XOR the two media together and write the result onto a third media your chances are very good.
Err, well, how about the fact that I have yet to see a portable or car CD player that plays a CD-ROM full of Ogg-vorbis files?
Today designing such a player with MP3 support but no OggVorbis support sounds like a bad idea. The fact that with the same storage capacity you can get more music at a better quality really should be the killer argument for such a device. And of course the MP3 royalities doesn't make the device cheaper, so at some point it would even be stupid to include MP3 support.
I can hardly tell the difference between OggVorbis at 45kb/s and the original noncompressed CD. Try MP3 at 45kb/s! I never saw one, the lowest bitrate I have seen used for MP3 encoding was 64kb/s, and the result certainly wasn't good sound quality.
Would be nice to use the same module I compiled in 2.4.1 in my new 2.4.19 kernel.
Sure, that would have been nice. But would it also have been nice, if 2.4.19 had to suck as much as 2.4.1 in order to make it possible? Sure it would have been nice, if 2.4.1 had not had the problems making the changes necesarry, but 2.4.1 did have problems and now they been fixed. (At least most of them have been fixed.)
And there's a good reson why you can't change your posts - can you imagine the havoc when someone decides to change their +5 Interesting post to read 'First Post!'.
Allow changing as long as it has not been moderated or commented on. And if a user find he has written something stupid, he should be allowed to mod down his own comments without that affecting his karama.
Even Linus is against the creation of standard interfaces internal to the Linux kernel.
First of all it is important to keep in mind, that there are two different kinds of interfaces:
Internal interfaces between parts of the kernel and kernel modules.
External interfaces used by user mode applications.
The later are aiming against complience with UNIX and POSIX standards. It is only the internal interfaces that can be changed without notice. But notice that as long as the interfaces are changed thorugh the entire kernel users are not affected. It does mean you cannot mix code from different kernel versions, but end users are not supposed to do that.
Of course the changing interfaces are a problem for anybody who wants to develop closed source driver modules. But Linus and other kernel developers does not like closed source modules, the modules impose a problem on anybody who wants to debug kernel problems. So Linus certainly doesn't want to stop kernel development in some areas just to help developers of such closed source modules.
Interfaces are not changed without a reason. Some developers of closed source modules might think interfaces are changed to annoy them, but of course that is not the case. However they do have to understand, that support from the Linux community cannot be expected before they open their own source. Hardware vendors must understand, that writing a closed source module does not make their hardware supported by Linux, a open source driver is needed before full support is existent.
Slashdot Mirror
Then why call it Embedded Linux Kernel Subset?
I think the word subset is an important one here.
Is GCC not supported on a 286? I think as long as you could run almost ANY operating system you can run GCC.
I have used gcc under DOS 6.20 on a 486. It was not particularily fast and did use protected mode. I know the 286 has protected mode, but I think gcc uses 32 bit code, which is not an option on the 286. It came with some runtime environment to setup protected mode and even included virtual memory. I later found the same virtual memory could help when running MCAFEE on a computer with only 4MB of RAM. It was implementing some standard whose name I don't recall.
Didn't 2.4.19 and before have a local exploit?
IIRC 2.4.20 has one as well. Vendor kernels are (should be) patched against it. But if you wanted a nonexploitable kernel from kernel.org you'd have to use a prerelease. Nobody wanted to rush 2.4.21 through because of that particular bug.
you should see "swapper" (or something similar) floating around in there.
On Linux "swapper" is usually the idle thread that gets the CPU when nobody else needs it. That process basically runs an infinite loop calling the HLT instruction. I think it is the "kswapd" process you had in mind. Cases have been seen where kswapd would use a lot of CPU time. I'm not sure it was caused by the harddisk drive. AFAIK it happened under high memory pressure. It might even be that more swap available would have speeded up kswapd. If you really have a lot of CPU usage in your harddisk driver, you should see larger system percentages caused by other processes accessing the disk.
Even when it was done creating the thumbnails, it still ate up CPU and ram.
I never experienced that problem. Could be you have run into some weird KDE bug rather than just a bloated feature. Personally I like having those thumbnails created. As long as you don't have to wait for it to complete before proceeding with your work, and it stops when you close the window, I don't see a problem.
If I am using under x percentage of physical RAM, my system doesn't touch swap. At all.
Under Linux I don't think any swap will be used before you get low on physical memory. I think you might be able to push the usage as high as 95% before swap is being used. The algorithms used in Linux are not perfect, but quite good. It should be possible to have the same page in physical RAM and on swap at the same time, I don't think Linux can do that. The advantage is that you can write a lot of pages to swap long time before you really need the memory. Then you can reuse the physical memory quicker than you could have done if you first started writing when you actually needed the memory. Of course premature writing to swap should only happen if the disk is otherwise idle and has not been idle long enough to cause a spin down.
Perhaps our Danish Slashdotters could fill us in about the organizations who funded this study.
The Danish "newspaper" Computerworld had an article about it. But unfortunately it is not completely clear who is behind the study. It says "Arbejdsskadestyrelsen og ankeinstansen" (agency of industrial injury and the appeal tribunal) will be using the results to judge whether the damages can qualify as industrial injury. It also states that head of the study consultant Johan Hviid Andersen at Herning central hospital has pointed out that it is too early to completely rule out, that mice can cause damages. And he still advices people working at the screen at least 20-25 hours a week to take care of themselves and take many small breaks during the working day. The final report is expected to be finished by October.
What is the processor spending its time on? wait() for the storage to catch up?
You cannot easilly tell. At least top is not going to help you there.
playing with swap?
CPU playing with swap? It doesn't, it starts the controller, and then go doing something else until an interrupt arrives from the controller. Sure if you don't enable DMA the CPU does have to spend a lot of CPU time in the driver, but usually you will spot the higher system percentage in top if that is the case.
handling interrupt requests?
Unfortunately top does not tell me how much CPU time is spend handling interrupt requests. But interrupt requests are not supposed to use more than a few cycles of CPU time. If more time is needed the code should be executed in some other context scheduled by the interrupt.
creating fucking thumbnails?
If you want thumbnails of your pron collection, you will expect fucking thumbnails won't you?
The CPU is rarely the bottleneck. 9/10 its the storeage, then the network.
True, and that is obvious from the output of top.
make sure you don't hit swap (I have swap for the sole purpose of a kernel dump after a panic. 1xRAM + 30M to make sure there is enough space.)
Too litle swap can slow down your system. To most people it is not obvious, but swap does give the system the oportunity to swap out unused data, so the physical memory can be used for something better. Though I don't always agree with my kernels decissions on what is the best way to use my physical memory. Finally more swap can sometimes avoid those nasty consequences from the kernel overcommiting memory.
Back when it took Intel a long time to come out with a new CPU architecture or speed boost, programs would see tremendous performance boosts between versions as the programmers would have time to optimise to the *existing* hardware.
I recently heard something interesting about the game hitman 2. The first version was not available for PS2, but the new version is. They had to do a lot of performance tweaking because of the slow CPU and small amount of memory in the PS2. The end result actually was that even the PC version because of those code improvements does not require more computing power than the previous version (except from on the graphics board).
My webservers see serious cpu loads
Do you know how much time your CPU spends computing and how much it spends waiting for data to arrive from your RAM?
On the other hand, in todays court climate, probably even having heard about the original source makes yours derived.
Hey, I'm pretty sure SCO and M$ have heard about Linux. Don't you think so too?
and wait a minute for the characters to agonizingly appear one at a time on the screen.
I tried different emulators on an A1200. And as long as you were just typing simple DOS commands the speed was acceptable. At least one of the emulators came with a native ANSI.SYS driver, that could speed up text output significantly. If you forgot to use such a thing, I can imagine it must have been slow.
christ, the amount of collisions
Collisions is not caused by driver problems. The way ethernet was designed simply means collisions cannot be avoided. The work done to limit the amount of collisions as much as possible is best done in hardware. If anybody was stupid enough to make hardware requiring those features to be in the driver, the hardware designers are to blame, not the driver designers.
Hi, the URL posted is obviously wrong.
Is this a new approach to prevent slashdoting?
It may be a violation of the license agreement
But then again such a license agreement could be a violation of the copyright law. In the country where I live, the law explicitly says the user has the right to decompile if that is the only way to find the necesarry information to make a program you are developing interoperable. And the law says that right cannot be given up by agreement.
I think that the GPL is actually a bigger threat than MS.
That depends on whose side you are on.
Counterfitters won't even try to adjust to the new bills if the old ones are still in circulation and legal tender - there's just no reason to.
I have always been wondering why they don't counterfeit the new ones which people are not so familiar with. Being unfamiliar with it, you should have a harder time realizing it was fake.
You haven't spend more than 10 seconds on it.
/, /usr, and /usr/local was discarded. If you really think they did such a great job, then why do you think they did not document it?
I have a lot more experience with the filesystem layout than that.
What makes you think they have not done this?
The information telling us that the seperation of
Linux has already made a mess out of the Unix FS.
/sbin/init and /etc/inittab is quite simple and really not any kind of mess, but all those rc scripts thrown on top is a mess. What I'd do is to add a few small features to /sbin/init and then get rid of all those rc scripts.
/sbin tools in /bin...
/sbin I often use as non-root user, so I simply need /sbin in my path anyway. So the only good reason remaining for different directories is the few executables in /usr/bin which are really a suid wrapper prompting for a root password before executing the real program in /usr/sbin. But those can be implemented in other ways.
I don't see why you think the filesystem is a mess. There are a few essential locations you should know the purpose of, and then it is all very intuitive. I have seen Unix systems worse than that. Why does anybody want to put ping in etc?
Oooo, this bit of SysV is shiny!
SysV initscripts is a mess, but that doesn't make the entire filesystem a mess.
Next thing they'll probably by popping all of the
That wouldn't be the worst thing they could do. Many of the executables in
I really liked the idea of reorganising directory structure.
/usr and /home I located on seperate partitions. This means I could backup my / partition on a bootable CD if I wanted to. With their reorganisation I don't think there is an easy way to split files into important files that need to be on / and less important files, that can be on a larger readonly filesystem which is not necesarry for the basic system maintainance tasks. Before reorganising you should identify the problems you want to solve, and you should understand why the system looks the way it does to avoid breaking the system. Finally you must ensure that your reorganisation in fact achieved the desired results.
Don't make reorganisations without a purpose. The current orginaisation might not be perfect. But to me it sounds like the change they made introduces new problems without solving any of the existing problems. Though I have installed a distribution taking up more than 3GB of disk space, less than 300MB of that is in the / filesystem. And in fact it was only
Fully standards compliant mpeg4. It's not going to look nearly as good as XviD or DivX5, but it will be "durable."
When considering durablity the physical media format is much more important than the encoding format. If your physical media is durable any encoding will be durable. Actually finding a decoder is another issue, having decoder source on the media together with the movie improves the chances. When XviD or DivX is called less durable it is AFAIK because they are often recorded with less error correction on the physical media. If you have more error correction and allow yourself to spend two medias on each film rather than one, your chances of not loosing the data improve. If you finally XOR the two media together and write the result onto a third media your chances are very good.
Err, well, how about the fact that I have yet to see a portable or car CD player that plays a CD-ROM full of Ogg-vorbis files?
Today designing such a player with MP3 support but no OggVorbis support sounds like a bad idea. The fact that with the same storage capacity you can get more music at a better quality really should be the killer argument for such a device. And of course the MP3 royalities doesn't make the device cheaper, so at some point it would even be stupid to include MP3 support.
I'm quite sure that OGG sucks compared to MP3.
I can hardly tell the difference between OggVorbis at 45kb/s and the original noncompressed CD. Try MP3 at 45kb/s! I never saw one, the lowest bitrate I have seen used for MP3 encoding was 64kb/s, and the result certainly wasn't good sound quality.
- Faster compression
- Smaller files
- Better sound quality
- Free technology
So what good reasons remain for using MP3? (Except from the tons of pirat MP3s you can download from the net.)Would be nice to use the same module I compiled in 2.4.1 in my new 2.4.19 kernel.
Sure, that would have been nice. But would it also have been nice, if 2.4.19 had to suck as much as 2.4.1 in order to make it possible? Sure it would have been nice, if 2.4.1 had not had the problems making the changes necesarry, but 2.4.1 did have problems and now they been fixed. (At least most of them have been fixed.)
And there's a good reson why you can't change your posts - can you imagine the havoc when someone decides to change their +5 Interesting post to read 'First Post!'.
Allow changing as long as it has not been moderated or commented on. And if a user find he has written something stupid, he should be allowed to mod down his own comments without that affecting his karama.
First of all it is important to keep in mind, that there are two different kinds of interfaces:
- Internal interfaces between parts of the kernel and kernel modules.
- External interfaces used by user mode applications.
The later are aiming against complience with UNIX and POSIX standards. It is only the internal interfaces that can be changed without notice. But notice that as long as the interfaces are changed thorugh the entire kernel users are not affected. It does mean you cannot mix code from different kernel versions, but end users are not supposed to do that.Of course the changing interfaces are a problem for anybody who wants to develop closed source driver modules. But Linus and other kernel developers does not like closed source modules, the modules impose a problem on anybody who wants to debug kernel problems. So Linus certainly doesn't want to stop kernel development in some areas just to help developers of such closed source modules.
Interfaces are not changed without a reason. Some developers of closed source modules might think interfaces are changed to annoy them, but of course that is not the case. However they do have to understand, that support from the Linux community cannot be expected before they open their own source. Hardware vendors must understand, that writing a closed source module does not make their hardware supported by Linux, a open source driver is needed before full support is existent.