Craig,
> 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.
What type of wireless hardware does your laptop have, BTW? There was a
large number of wireless drivers added in the SXDE 05/07 release and
the upcoming SXDE release has several more.
With respect to /bin/sh, I sympathize but changing /bin/sh itself will
take some time. I'm not saying it can't be done or won't be done but
there are many things that need to be done before we can cross that
bridge.
> * 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?
Which SXDE release were you using? "make" has been in the default PATH
since SXDE 05/07 along with a number of components that used to be in
/usr/ccs/bin. In the upcoming SXDE release, almost all of the rest
have been moved into /usr/bin as well.
Or are you referring to GNU make being in the default path? That too
will be present in the default path as /usr/bin/gmake (or if you put
/usr/gnu/bin in front of your path, it's available just as "make").
> * 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"!!!
Could you please indicate which CR this was?
> * 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 GNU version of "env" is also available in /usr/gnu/bin in the
upcoming SXDE release.
> 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.
One of the goals of the Solaris Modernization program which is being
accelerated due to Project Indiana is to create an OpenSolaris where
running ./configure "just works".
> 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.
So suppose more and more of the GNU tools are integrated into
OpenSolaris, living in their expected locations such as /usr/bin unless
they conflict with a preexisting version, in which case the GNU tool
ends up under /usr/gnu/bin. If you have /usr/gnu/bin in front of your
PATH, will these build scripts work? Or can you provide examples which
indicate that they really do need to be in /usr/bin in order to work?
What I'm trying to explore is can we build a sensible system that
supports both current/traditional users of Solaris while also
supporting the new developers we want to bring over to OpenSolaris?
One solution is to use some form of virtualization such as branded
zones or Xen. Another is create universes the way Pyramid did back in
the '80s. But those will take a significant longer effort that relying
on the simpler PATH scheme.
> 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 :-).
We're trying to do the latter (making something the Linux-familiar
developer will be comfortable with) while also maintaing compatibility
where it makes sense. And I suspect thay reasonable people will have
different definitions of which historical behaviors constitutes bugs.
:-)
> Give me the Linux userland, or give me Ubuntu! :-)
How about joining the effort going on at [EMAIL PROTECTED]
to incorporate more external open source into OpenSolaris? Already
there have been a lot of changes since SXDE 05/07
New components
==============
Bcc 0.16.17 (real mode x86 compiler)
GNU coreutils 6.7 (almost 100 commands)
GNU which 2.16
Nmap 4.20
Updated components
==================
BIND 9.3.4-P1
Bzip 1.0.4
Flex 2.5.33
GNU Bison 2.3
GNU make 3.81
ImageMagick 6.3.4-2
PostgreSQL 8.1.9
Samba 3.0.25b
Tcl 8.4.14
Tk 8.4.14
and there is an effort underway to fold the /usr/sfw components into
their expected location. After that, it's my hope we will do the same
for the Companion CD. In the meantime, we're working on moving the SFW
consolidation to Mercurial and for the repository to be outside the
firewall. But it will only go as fast as we have people contributing
to the effort.
dsc
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
