[...]
> > Not breaking compatibility is a sacred thing, and
> showing that Solaris can innovate and be a technology
> leader, and not break things because it's well
> *engineered* puts the Mr. Andrew "Rampant layering
> violation" Morton and the like to shame.
> >
> > My kind of people.
>
> not mine unless you want everything you have worked
> with to die on the
> grapevine. I always wondered why some unix variants
> would carry years of
> problems along, like dragging an elephant. I think I
> see why now.
There's no reason why one can't have both innovation and
compatibility.
I haven't seen too many {banks, stock exchanges, telephone companies}
that _wanted_ bleeding edge. They wanted something solid.
Most desktop type end users don't want bleeding edge either. They want
to do whatever they want to do as easily as possible, some part of which
is that it's also problem free, upgrades are a no-brainer, etc.
Those with prior experience in some other environment probably want
familiarity; that could be done without breaking the existing environment.
However, it's quite reasonable to expect stable versions of newer applications
and tools to be available out-of-the-box, as long as alternative versions
can be found conveniently but not as defaults in any sense that would break
existing scripts or applications. If you want something newer than stable,
you should expect that to come strictly from a community, not mostly
from a corporation, IMO. I wouldn't expect anything less than that
distinction.
If you want an environment that will make it relatively simple to port
Linux apps to Solaris, that's yet another thing; a branded zone that's _not_ lx,
but has a Linux-like personality in terms of tool set and such might be an
answer, along with maybe getting the OSS drivers working better on
both SPARC and Solaris x86 (including the compatibility devices), and
available out-of-the-box, along with maybe some enhancements for
_source_ compatibility for networking and a few devices. That, along
with a few guidelines ("don't assume that /bin/sh = /bin/bash if you have
embedded scripts"), should help porting apps that would then run in either
that environment or in a generic Solaris environment. The work that's
allegedly ongoing to allow Studio C++ to have the option of generating
g++ ABI compatible code would also help, IMO, esp. combined with
stuff like gccfss (gcc framework, source language, and command line,
Studio code generator - nice to have the like for x86, too, or alternatively
to feed back some improvements to gcc's code generation to have the
best of both in one), would together with the rest, and some tools
already available (if not yet distributed with Solaris), make porting
apps from Linux to Solaris _much_ easier in most cases.
Back on the user side, if the recently restored virtual console support
(which before the old version got yanked, only x86 had) would support
graphical logins to different zones on different virtual consoles, along
with an option to switch to a non-global zone's virtual console after it's
booted, one could interactively log in to an environment that one would
rarely be aware wasn't Linux; and yet not affect the "normal" Solaris
environment. All that stuff could be a very easily chosen installation
option, yet just as easily left out for minimized installations.
Most of the pieces are here to do this sort of thing now, without hurting
anyone. A few more pieces are needed, and then it all has to be brought
together.
And IMO, for anybody that thinks that still wouldn't be good enough,
either they should use an existing GNU-on-OpenSolaris-kernel distro like
Nextenta, or they're not looking to solve a problem, they just want Linux
and nothing else, in which case they should just go there and leave us in
peace.
In other words, there's certainly some room for work and accomodation,
but accomodation goes both ways: don't expect to be allowed to mess
things up for those who are already here (your way might be right for you,
but it's not right for those already invested in something else), don't expect
to rule by force (or by who yells the loudest, either).
But you want to talk cooperation? Let's see some more app developers
learn how to write portable code, or at least accept patches to support
additional platforms! (I'm still royally ticked that the Hercules folks
disclaim any interest in patches for e.g. a Solaris port. I'd be more willing
to work on that, and try to find other people to help, if they'd take it
once it was working and reasonably clean. I can just imagine what that
would scream like if built for 64-bit and running on a multi-Rock or SPARC64VI
system...assuming it would scale to more than traditional x86 4 core setup.)
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
