On Fri, Jan 30, 2009 at 1:19 PM, Miles Nordin <car...@ivy.net> wrote: >>>>>> "fm" == Fredrich Maney <fredrichma...@gmail.com> writes: > > fm> changing the default toolset (without notification) > > I wouldn't wish for notification all the time and tell people they > cannot move unless they notify everyone, or you will get a bunch of > CYA disclaimers and still have no input.
Neither would I, nor is that what I asked for. I would however like to see changes like this documented in Release Notes or the Project Page. Unfortunately, that doesn't seem to happen as often as it should. > And if you won't take the > time to discuss and compromise, you should not be allowed to block > people trying to improve things by demanding they seek you out, beg > for Your Obstinence's attention, and yeild and appeal for the > generosity of your blessing before they can move. Are you looking down your nose at just me, or everyone that is not amused with the "it's new, therefor it MUST be better" crowd? > This is the recipe for a stagnant, bit-rotted system, and it's the > *FIRST* attitude the Linux camp threw over the railing. > > fm> from the expected native tools to external tools in order to > fm> "make OpenSolaris more user friendly and familiar to the Linux > fm> crowd". > > Yes! I agree it's a very bad reason. I've yelled at not a few Linux > people who came to BSD and complained the installer wasn't friendly > because it didn't have white-on-blue text. I told them we are > building an OS so here are the .tar.gz which is all I ever use, so > don't talk to me of this remedial installer. If you want to build > installers only, you know where to find the other tent. > > ``The old tools are unmaintained, ancient and not supporting expected > modern standards and features needed to get work done conveniently, > and not supporting the stream formats and shell scripts of most other > systems (not just Linux ones!), AND don't come with source,'' are > several really good reasons. I think you are WAY too easy on > yourselves to say these people want something familiar when some of us > really want something that works well and is not frozen or abandoned. All of those statements are subjective viewpoints. I look at the feature sets for the "ancient" tools and see a lot of features that are missing from the GNU alternatives as well as a lot of patches pointing out the lie in "unmaintained". Just because they don't have the feature de jour found in the latest unstable build of the so roll your own and smoke it Linux distro doesn't mean that it is unmaintained or ancient. > However, just moving the path around is not enough. Whatever tools > are going to be the Default ones, the ZFS-specific features need to be > added to THOSE tools, not just to some tools somewhere that I have to > go hunting for. which is how this thread began. It wasn't about > ``OMG a GNUism! why was I not INFORMED?!,'' it was about why is this > ZFS feature missing from the Default tool? This thread began because of a feature that was expected, and present in previous versions, was suddenly missing, due to a fairly significant change (in impact, not amount of work involved) that was, to all appearances, arbitrarily made and never communicated. > This probably means there should eventually be ONE set of default > tools, unless we are really going to meticulously add these ZFS ACL > features and every other future architecture to both GNU and ancient > usr/bin tools and ancient xpg4 tools and xpg6 tools and ucb tools and > ancient 5bin tools, forever. Agreed. Oddly enough, that seems to be the path was taken by Sun quite some time ago with /usr/bin. Those tools are the standard, default tools on Sun systems for a reason: they are the ones that are maintained and updated with new features (some internally developed, some ported from elsewhere where possible and useful). [...] fpsm _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
