On 20 Feb 2003, at 9:41, Henrik Nordstrom <[EMAIL PROTECTED]> wrote: > On Thu, 20 Feb 2003, Andres Kroonmaa wrote: > > > Hey, watch your words, i'm Solaris shop ;) > > I am free to express my opinion. Any my firm opinion in this matter is > that the Solaris 32 bit STDIO subsystem limited to fd < 256 is just crap > and seriously crippling the Solaris system for absolutely no reason.
ah, of course you are, just calling names is not cute ;) Solaris is damn good os, despite all its conservativeness. There was reason. initial stdio posix.1 spec was crippled if you like. It lacked means to access FILE struct and coders had to do that outside specs, directly accessing FILE structs. Changing stdio rudely was freedom, but it would have broken alot of business and scientific environments depending on that, and it was hard choice. Linux has always had luxury to pull the plug between versions, and noone really expected binary compatibility from it. Sun decided that leaving this stdio alone was less damage than loosing ability to run old binaries natively, especially given that apps needing >256 files open can workaround the limitations and at least notice the limitation during responsible testing. > > When I first encountered this issue, I was told by Sun tech with sad > > mode that yeah, sux, but thats invented looong ago that FILE has 8bits > > for FD, and that they are forced to drag this along all the way for > > backward compatibility. He also began shining suggesting 64-bit api. > > Considering binary backward compatibility as crippledness is something > > we owe to linux. > > This is not even about binary backward compability. They could easily have > solved the problem in binary backward compatible ways the day SunOS > started to support more than 256 filedescriptors per process, only > requiring certain broken applications and libraries to be recompiled to be > able to use more than 256 filedescriptors. Using binary compability as an > excuse for not doing anything about such silly thing is intentional > crippling of the system in my view. It is about binary compatibility, and it isn't even about the FD itself, but about rest of the FILE struct offsets. Stream state flags mostly. In heavily MP apps that had to know state of streams. it was easy to do on OS side. It WAS considered, it was pushed, weighted, and it was decided that it would cause more harm. recompiling large complex mission-critical apps for just this silly thing would cause only amuse, and huge risks and expenses. Sun built new hardware that needed new OS for its support, and old binaries had to run natively. Sun wasn't building exactly $1k desktops, and not for exactly hobbysts.. It had to listen to its customers. Why such disrespect, I'm amazed? Leaving alone API that works for 99.999% of apps hands down, instead of pursuing perfectionism and force to recompile bunch of critical but damn old apps that don't even need >256 files, but need to run on different OS versions in NFS environment, compared to those few that can make trivial workarounds, is that crippling of a system? nah, but I don't really care. Solaris has lf64 for years now. ------------------------------------ Andres Kroonmaa <[EMAIL PROTECTED]> CTO, Microlink Data AS Tel: 6501 731, Fax: 6501 725 Pärnu mnt. 158, Tallinn 11317 Estonia
