On 8/6/07, Ché Kristo <[EMAIL PROTECTED]> wrote: > [snip] > maybe where it makes sense to do so, perhaps when a user tries to run say top > we could spit out a url to a page explaining why tope is not there and how > Solaris/Indiana does it better > [snip]
OK, I'll bite. I'm a Sun employee (and heavy user of Ubuntu) that is extremely disillusioned with everything I have seen that Open Solaris has done so far. I tried Solaris Developer Express (several iterations). I really tried. I can deal with the fact that it didn't know about my laptop's wireless hardware (Ubuntu didn't either until Fiesty). But I can't deal with the historical Solaris legacy that comes with /bin/sh being Bourne shell, and associated atrocities. * I tried to install (from source) some typical open source software like Apache 2 (yes, that particular package is available as binary, but the principle here is the important thing). Wait a minute ... the GNU build tools and make are *not* on the default path. For a *developer* edition? Excuse me? * The response to my bug report on this was sad ... "use dmake ... it's a lot better." I DON'T CARE -- THE BUILD SCRIPT FOR THE CODE I WANT TO BUILD USES "make" NOT "dmake"!!! * I work in the Java Tools group, so naturally it makes sense to try to build NetBeans from source. Turns out you can't ... /bin/env on Solaris Developer Express (Bourne shell legacy) cannot handle command lines that the Ant build script for NetBeans emits. And it's not just NetBeans ... this limitation causes problems building *lots* of typical open source C/C++ software. The Internet has a vast number of OS packages available as source, easily compiled and installed with the typical "./config ; make ; make install" pattern. Yes, binary packages are nice for end users, but they are useless to most developers who want to stay on the cutting edge of at least packages relevant to what they are working on. And the vast majority of such packages, IMHO, have Linux-ish assumptions in their build scripts. So, if we can't be "duck typing" compatible with Linux, again IMHO, Indiana is not going to be good for much. Can we fix this, please? The planets are aligning so that people might actually *like* a break from backwards compatibility with Solaris (including backwards compatibility with some really nasty historical bugs :-). PLEASE make Indiana into something that a Linux-familiar developer will be comfortable with -- except, of course, for the fact that it runs more threads and scales better to multicore processors :-). Give me the Linux userland, or give me Ubuntu! :-) Craig McClanahan <[EMAIL PROTECTED]> PS: Is there a reason this list is not "reply all" by default? _______________________________________________ indiana-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
