Ashley M. Kirchner wrote: > Craig White wrote: >> Come to think of it, I don't recall ever seeing savvy administrators >> whining over a new scripting challenge, especially something that is >> this easy. >> > It wasn't meant as a whine in the sense that it can't be done or that > I had to do it, but more a complaint of having to do it *because* of > someone else's decision to implement that limitation. I'm being forced > to do one of two things: either rotate logs more often and write a > wrapper around the rotation, or rebuild syslog (and whatever other > utility needed to make this work.) Neither of which are necessary if > that limit wasn't implemented. Again, I don't see any reason why it > still exists. > It isn't that someone decided to implement a limitation, but that they didn't program around a limitation of 32 bit processors. The limit is imposed by using the standard GNU libc as compiled by gcc on 32 bit processors. Considering that 1G hard drive was a large drive at the time it was implemented, it was not unreasonable to accept a 2G size limit. The fact that system memory and hard drive sizes progressed much faster then processor size has led to ways of handling larger files on 32 bit processors, but you have to use them. It tends to be more then just changing a function call. It also tends to make the program run slower, because you need more cpu instructions to do the same thing. I don't believe the same programs, compiled on a 64 bit system, have the same problem. When you are using the 64 bit version, the sizes used are 64 bit instead of 32 bit without changing anything in the program. This is part of the reason people are moving to 64 bit processors, and the 64 bit versions of Linux. Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
