> Perhaps different people are talking about slightly different things.
> Here's my attempt at disentanglement.
>
> 1) High order goal (perhaps the highest for Indiana) remove barriers
> to entry for the Linux trained.
>
> A) Highest order goal for Solaris (classic) don't ever break anything
I don't know if those are the highest order goals but they're certainly
near the top.
> For the question of what to do about /bin/sh (especially since it's
> encumbered) I don't think that having it be ksh93 should be a
> showstopper for the Linux newcomer ... we might be sports and have
> the default prompt be something other than a simple # for root to
> make it explicit that we're in ksh93 (e.g. ksh93#).
Just a point of clarification - /bin/sh isn't encumbered, it's just
old. And that affects the current OpenSolaris in two ways I think
1) Users who are unfortunate enough to have /bin/sh as their
shell are in for a rather trying experience, especially if
they've come to rely on things like history and command-line
editing. One of those users does happen to be "root" although
again, that's just a historical convention. I suspect that
changing root's own shell to something like /bin/bash or
/bin/ksh is a much easier first step than changing /bin/sh
itself.
2) Users have begun to write scripts that depend on the details
of different implementations of /bin/sh. Given that the
OpenSolaris /bin/sh is of a very old and unique vintage, some
of those scripts don't work or need work in order to get them
working on OpenSolaris.
Although it's interesting to see all the comments/votes on what to
replace /bin/sh with, what I haven't seen is any sort of analysis. For
example, what choices have other OS distributions made here? What sort
of standards do the various contenders adhere to? And more
importantly, how are each of the contenders compatible with each other
and especially the current /bin/sh. If we're going to change /bin/sh,
what is the upgrade path for those users *and* ISVs who are already
depending on the current behavior (yes, I said ISVs because a number of
them have spoken to me that they've already made allowances for
OpenSolaris' /bin/sh and a change would affect them too!)
> Perhaps more entertainingly, can we somehow make RBAC work invisbily
> enough that for the "standard" developer desktop that a special sudo
> is just a default shell function which does the right pfexec (or
> pfksh or whatever the ideal syntax is) and have the SXDE/Indiana
> default be to create a user account which has the right privs?
I think that would be a great idea and I'd love to hear someone more
familiar with both technologies to see what can be done in this space.
That said, if the models really cannot be reconciled or there isn't
someone willing to do the work, I'm of a mind that we should be looking
to integrate sudo as-is barring, of course, a proper security audit.
> Retraining their fingers (and minds) is a huge barrier as Tim aptly
> noted. Migrating them to a better facility (if to a first
> approximation it does the "same" thing for the 99% use cases) can be
> a compelling story.
>
> However, if it's "better" but different in the first N things the
> poor user tries, it's not likely to be used enough for the
> "betterness" to matter.
Agreed - it's a tricky and potentially slippery slope in this area.
dsc
_______________________________________________
indiana-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
