> Second - backwards compatibility is something we take > seriously but it > isn't an absolute. Not even in the Solaris world.
Apparently not. > That's really strange because on my laptop which is > running the Indiana > prototype released on October 31st, I see exactly > > SunOS myhostname 5.11 snv_75a i86pc i386 i86pc I can boot the thing again and cut & paste `uname -a`, not that it matters much if it's an artifact as you write. > We're not in Linux land but we're also not in Kansas > or Murray Hill > either. This particular change was actually PSARC > approved back in > 2003 as > > PSARC 2003/039 Alternate home directory for root > t user > > Unfortunately that case has been opened but I'll put > in a request for > that to be done. The case documents a number of > reasons for making > this change but I would argue that being consistent > with the larger > number of other systems including Linux and the > various BSD > distributions makes a great deal of sense. The most important thing here is to remain consistent with System V, not try to emulate an "GNU is NOT UNIX" OS. People come to Solaris because of ZFS, primarily, and because of DTrace, not because of anything else. So long as Solaris keeps innovating and delivering technologies people want but can't get elsewhere, they will be compelled to come to Solaris and use it. It's a value proposition and it has justification. Trying to look and behave like what is currently fashionable, aka /root and /usr/gnu/bin will not be the deciding factor. That isn't innovation, that is immitation. > but it would be appreciate if you could file a > separate bug for the > case of dealing with multiple drives. I'll see to it that it gets done. > We should release note this - the file you need to > edit is actually > /zpl_slim/boot/grub/menu.lst as that's the version of > the file at the > top of the root pool. This issue is filed under > > http://defect.opensolaris.org/bz/show_bug.cgi?id=71 /boot/grub/menu.lst will eventually lead to /rootpool/boot/grub/menu.lst though? >From my point of view, that would follow the principle of least surprise, and >be the sane thing to do. > I believe /etc/passwd is set up in the new package > system as a > preserved file so upgrades to new builds should not > result in the entry > for "root" being changed back. That doesn't help me. Our builds are Flash(TM) builds of fresh installs. > Well, it's certainly possible that a default > *interactive* shell of > "bash" may result in more bash scripts, but I think > most folks > recognize the differences between interactive and > scripting uses of the > shell. I do not believe this to be the case, not at all. In fact, in my experience, the exact opposite is true. People use /bin/bash because they don't know any better. If one prefers a Bourne-familiy shell, that's all good and well, but there's no need for bash at all; there's ksh, ksh93 and then there's zsh, all good shells with good compatibility. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
