>
> --- Gueven Bay <[EMAIL PROTECTED]> wrote:
>
> > Maybe the Solaris people should adapt some things
> > from Linux. But I vote for staying in the "Solaris
> > way". I don't vote as the linked press articles say
> > for bringing more Linux-isims into (Open)Solaris.
> >
> > For example a better package manager: Okay. But
> > build it on top of the pkg_* commands which are in
> > Solaris today AND explain, show and teach the users
> > the Solaris way.
>
> Why? Please give a technical argument in favour of
> this and not just some stupid emotional attachment to
> the "Solaris way".
Changing this would break the Solaris user base, and require extensive
retraining for all existing Solaris administrators.
The SVR4 pkg tools are capable of handling (or could be extended to
handle) pretty much anything that any other packaging system can provide
for. They had already been extended to be zone-aware, for example
(and probably they handle a number of other unusual cases that I don't
happen to know about).
With the pkg-get script, SVR4 pkgs can be fetched over the network, along
with their dependencies, given a suitable repository. With pkgbuild, they
can be built from spec files almost identical to rpm spec files. If one
wished, one could have an arrangement whereby one either fetches the
binary package, or fetches a parallel source package including spec file, built
it automatically, created the binary package, and installed it automatically,
with one command to start the whole process. AFAIK, no new tools would
be needed to do that. If all one wanted was to provide familiarity to
existing Linux users (nothing wrong with that, not that I care one way or
another about them except that I wouldn't mind some more cooperation from
some of the application developers), wrapper scripts would take care of
all but the trickier cases, and help and documentation could probably be
provided for those.
Distributing pkg-get and pkgbuild with Solaris (plus maybe some no-brainer
GUI environment like Tcl/Tk or whatever to wrap a GUI around it for those
who just can't stand to learn anything before getting started) would be
part of the problem; easy, except perhaps procedurally or whatever. The
hard part would be having the repository. Something a lot like blastwave
actually, but with more newer packages built separately for newer OS
versions, and maybe with dependencies in sync with JDS versions of various
desktop components so they don't have to have those separately. And
much bigger - lots more packages, a uniform meta-build environment
(source code management, spec files, etc), maximum push to get patches
back to the upstream source and participate in maintenence of the Solaris
port at that level, etc.
And there's never too much training or documentation. Just getting
docs.sun.com more responsive would be a step; having a continuum
rather than a quantum leap from droning task guides to opaque reference
documentation would also help, IMO. And while I haven't yet bought the
Solaris Internals books (although there's a copy that I can and should borrow,
so I can decide whether to spend the nontrivial $$ for them myself),
I think an overall map that included pointers to all the above plus existing
troubleshooting docs (like the dtrace guide) and went beyond to all
available source walkthroughs (and always more!) would bring it all together.
> > Instead of going to Bash I would vote for
> > multi-media traings which show and teach Ksh and
> the
> > coming Ksh(93 I think) and its diffs to Bash so
> that
> > people learn the Solaris way.
>
> Not necessary. bash is available for Solaris and I do
> not fancy learning another shell.
Nobody says you can't use bash, which is already on Solaris along with
csh, ksh (-88 variant for now, but that's being worked), sh (Bourne, give
or take some possibly divergent evolution), tcsh, and zsh.
Consider that I and many others have similarly been using ksh for about as
long as bash has existed, and that others like tcsh or whatever. That's fine.
OTOH, making /bin/sh equal bash would be nuts, IMO. Better that scripts
specifically intended to be used with /bin/sh limited themselves to the least
common denominator of {Bourne, Almquist, Korn, bash, generic POSIX
standard, zsh} shells. Or be specifically identified as #!
/bin/something_other_than_just_sh. But the shell that responsible script
writers use doesn't have to be the same as what they or anyone else uses
interactively; I suppose they don't even _have_ to limit themselves to
POSIX compliant features, although whenever reasonable, it would be a
polite gesture.
> > Maybe even showing how system relevant shell
> scripts
> > in some linux distributions could be implemented in
> > Ksh so that one can develop for *Linux and
> > (Open)Solaris.
>
> You must be off your rocker. Why would I want to
> port,
> for example, Redhat's initscripts and the
> /etc/sysconfig directory to Solaris. Or do you want
> to
> tackle Debian's? Even within Linux space, system
> scripts are already a headache when moving from one
> Linux distro to another. Please get off your
> pedestal.
So why should Solaris be any different? If it's going to have headaches,
it ought to be its own, thought out to satisfy the needs of its user base,
and not simply someone else's adopted wholesale.
> > That would build skill sets, that would "empower"
> > the users and possible developers.
>
> We have more than enough scripting tools to learn.
> One
> can very well use bash in his own shell scripts if
> one fancies.
As long as one specifies #! /bin/bash or whatever, I don't care if that's
done. Just don't pretend that the rest of the world treats sh = bash just
because you like to.
This message posted from opensolaris.org
_______________________________________________
opensolaris-discuss mailing list
[email protected]
