You don't specify whether you compiled C or C++ programs. For latter the executables are naturally bigger since they are compiled with exceptions on. Try the -fno-exceptions compiler flag to see if there are any changes.
I guess this is a bit late and nobody reads this. However it's not necessary to apply all those patches by hand. For example I have a download directory where I download all the patches then I simply write:
Yes, that's certainly true. This kernel archive splitting business has been beaten to death many times. It's even in the FAQ.
Btw. here's a link which illustrates the growth of the kernel archive. (thought I had to advertise this somewhere since I bothered to do it:) The kernel source is such an attractive data set don't you think?-) In future I'd like to include more detailed breakdowns of the various parts and maybe do some analysis and predictions of the future growth.
http://www.helsinki.fi/~amlaukka/kernel-size.htm l
Don't mind the script. It's a result of couple hours worth of spontaneous hacking. It's interesting to see that since the late 1995 the growth has been pretty linear and amounts to about 200 kBs worth of bzip packed kernel source per month.
This list isn't organized per processor architecture though and it doesn't carry information about the current state of the port. For example the Sun3 port just recently got into a state where it can boot to a working system with userspace applications. The problem is that they can't share binaries with the rest of the m68k ports because of the different page size (8kB vs. 4 kB).
I'd say it could be accounted as a benefit for the NetBSD that a some of these m68k platforms (and some others) are better supported under it but on the other hand nowadays the said platforms are exceedingly hard to find anywhere.
Have you tried the magic sysrq feature in the new 2.2.x kernels? The console lockup often happens because the keyboard is left in RAW mode. There is a key combination for changing it back to XLATE.
I feel obliged to correct some of the most glaring FUD in this post. Yes, Jon Taylor was hired by Creative Labs - first and foremost programming Linux drivers for their sound cards (SB live etc). No, he wasn't the KGI "head developer" and no KGI is not turning into "a mostly binary only project". I suggest you to read the mailing list archives at http://www.ggi-project.org/ for the real details.
Slashdot Mirror
You don't specify whether you compiled C or C++ programs. For latter the executables are naturally bigger since they are compiled with exceptions on. Try the -fno-exceptions compiler flag to see if there are any changes.
I guess this is a bit late and nobody reads this.
/usr/src/linux/scripts/patch-kernel
.gz and .bz2 patches and automatically from say 2.2.0 to 2.2.5.
However it's not necessary to apply all those patches by hand. For example I have a download directory where I download all the patches then I simply write:
$ pwd
/home/amlaukka/stuff/kernel
$
and whoopla it patches the kernel up to the current version. Works with both
Yes, that's certainly true. This kernel archive splitting business has been beaten to death many times. It's even in the FAQ.
:) The kernel source is such an attractive data set don't you think?-) In future I'd like to include more detailed breakdowns of the various parts and maybe do some analysis and predictions of the future growth.
m l
Btw. here's a link which illustrates the growth of the kernel archive. (thought I had to advertise this somewhere since I bothered to do it
http://www.helsinki.fi/~amlaukka/kernel-size.ht
Don't mind the script. It's a result of couple hours worth of spontaneous hacking. It's interesting to see that since the late 1995 the growth has been pretty linear and amounts to about 200 kBs worth of bzip packed kernel source per month.
Here is a site which aims to list all the supported and experimental ports.
h tml
http://www.ctv.es/USERS/xose/linux/linux_ports.
This list isn't organized per processor architecture though and it doesn't carry information about the current state of the port. For example the Sun3 port just recently got into a state where it can boot to a working system with userspace applications. The problem is that they can't share binaries with the rest of the m68k ports because of the different page size (8kB vs. 4 kB).
I'd say it could be accounted as a benefit for the NetBSD that a some of these m68k platforms (and some others) are better supported under it but on the other hand nowadays the said platforms are exceedingly hard to find anywhere.
Have you tried the magic sysrq feature in the new 2.2.x kernels? The console lockup often happens because the keyboard is left in RAW mode. There is a key combination for changing it back to XLATE.
I feel obliged to correct some of the most glaring FUD in this post. Yes, Jon Taylor was hired by Creative Labs - first and foremost programming Linux drivers for their sound cards (SB live etc). No, he wasn't the KGI "head developer" and no KGI is not turning into "a mostly binary only project". I suggest you to read the mailing list archives at http://www.ggi-project.org/ for the real details.