Alexander <[email protected]> wrote: > > The GNU tools do not even support Linux specific > > features, why do you believe > > that they will ever start supporting Solaris specific > > features? > But in other case we have the following case: > 1) A lot of users (and what is more significant, developers) get used to work > with GNU tools. So, even to compile firefox we need GNU userland.
This is not a primary result of the "extra features" but a result of the fact that Sun did neglect the universities in the second half of the 1990s. Up to 1995, Solaris was the major development platform for most software projects. Later, more and more projects started on Linux and as Linux is not standard compliant enough, this resulted in a lock out for Solaris as the related projects did not follow the rules from the OSS movement that have been in used over 15 years before: Write portable code and communicate with people from other OS platforms. Some non-cooperative people started to pray that developers do not need to take care about the so called "proprietary" platforms because there is Linux. Another mistake from Sun was to neglect the Solaris userland programs since the same time the students have been neglected. Now we still do not have a situtaion where there is not way to escape from. The FSF neglects the "GNU tools" sincs aprox. 1994, when the habbit of Mr. Stallman caused most of the developers to stop working for the FSF. There are now new developers but the development (if you still like to call it development) is extremely slow. GNU tar fixed a show stopper bug 2 years ago although the bug was reported by me in 1993 and I am still waiting for a fix on a major GNU make bugs that was reported by me and accepted as a hard bug by it's maintainers in 1997 already. Now we have a OpenSolaris community and the Solaris userland could be enhanced by the Community. I e.g. have several enhanced and bug-fixed OpenSolaris tools waiting for integration back into OpenSolaris for years. Let's see whether Sun eventually takes this chance.... > 2) But a lot of Solaris native utils, respectively, relies on > Solaris-specific behavior. > And as result both kind of tools should be supported.... Quite strange... The theory says that OpenSource development makes it easier to collaborate but in fact, OpenSource development resulted in more incompatibilities and less collaboration than before. Try e.g. to count the number of SSL implementations that are "needeed" on OpenSolaris in order to make all software usable..... > May be there are some ways to make GNU tools at least do what Solaris tools > can do (to improve end user experience)... At least, why there can be some > objections from GNU projects commiters if patches for GNU tools enhancing > their functionality on Solaris are suggested to them? Did you ask Linux users why there is no Linux support in the GNU tools? > Of course, another way is to make own Solaris tools more GNU-like (for > example as it is done in FreeBSD). It will make life of developers (and > admins trying to compile soft on Solaris) easier. But it is not always > possible... FreeBSD is a good example for UNIX based development that still includes a maintained own userland. If the strategies for OpenSolaris will not be changed soon, we will end up with a OpenSolaris kernel only and then nobody will use Indiana as people may switch to nexenta.... > Just one funny sample. When I tried to compile new version of firefox on my > terminal server (SXCE b97) half year ago, firefox itself wanted GNU userland. > But some of its subcomponents (don't remember which) saw that it is Solaris > and tried to use Sun cc flags... Well, it is still possible to write portable software that does not require GNU tools for compiling. I am of course not using a recent GNU autoconf for my software as a recent GNU autoconf requires bash but I use "schily autoconf" which is a very enhanced version of the latest portable GNU autoconf-2.13. I am not using GNU make but my own "smake" which is older than GNU make and more portable than GNU make. BTW: If you fetch the complete schily source consolidation from: ftp://ftp.berlios.de/pub/schily/ you get something that contains the smake source and a portable shell based bootstrap to compile smake without a local make program. If you like to support high portability, you usually cannot rely on the local make program but this is definitely the only problem with portability. For everything else, you do not force people to use other then the local userland. Jörg -- EMail:[email protected] (home) Jörg Schilling D-13353 Berlin [email protected] (uni) [email protected] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily _______________________________________________ opensolaris-discuss mailing list [email protected]
