What is wrong with this? # chmod -R A+user:webservd:add_file/write_data/execute:allow /var/apache chmod: invalid mode: `A+user:webservd:add_file/write_data/execute:allow'' Try `chmod --help'' for more information. This works in a zone, works on S10u5, does not work on OpenSolaris2008.11. CT
On Wed, Jan 28, 2009 at 11:07 PM, Christine Tran <christine.tran at gmail.com> wrote:> What is wrong with this? > > # chmod -R A+user:webservd:add_file/write_data/execute:allow /var/apache > chmod: invalid mode: `A+user:webservd:add_file/write_data/execute:allow'' > Try `chmod --help'' for more information. >Never mind. /usr/gnu/bin/chmod Can we lose GNU, gee louise it is OpenSolaris2008.11 isn''t it. ls [-v|-V] is messed up as well. Blarhghgh!
Hit this myself. I could be wrong, but from memory I think the paths are ok if you''re a normal user, it''s just root that''s messed up. -- This message posted from opensolaris.org
On Wed, Jan 28, 2009 at 11:16 PM, Christine Tran <christine.tran at gmail.com> wrote:> On Wed, Jan 28, 2009 at 11:07 PM, Christine Tran > <christine.tran at gmail.com> wrote: >> What is wrong with this? >> >> # chmod -R A+user:webservd:add_file/write_data/execute:allow /var/apache >> chmod: invalid mode: `A+user:webservd:add_file/write_data/execute:allow'' >> Try `chmod --help'' for more information. >> > > Never mind. /usr/gnu/bin/chmod Can we lose GNU, gee louise it is > OpenSolaris2008.11 isn''t it. ls [-v|-V] is messed up as well. > Blarhghgh!There was a very long discussion about this a couple of weeks ago on one of the lists. Apparently the decision was made to put the GNU utilities in default system wide path before the native Sun utilities in order to make it easier to attract Linux users by making the environment more familiar to them. It was apparently assumed that longtime Solaris users would quickly and easily figure out what the problem was and adjust the PATH to their liking. Whether or not this was a good idea remains to be determined. From my vantage, it makes about as much sense to make Solaris more Linux-y in order to attract more Linux users while annoying current Solaris users as it does to change the speedometers on cars in the US to metric in order to make it more comfortable for immigrants and tourists to drive. fpsm
> There was a very long discussion about this a couple of weeks ago on > one of the lists. Apparently the decision was made to put the GNU > utilities in default system wide path before the native Sun utilities > in order to make it easier to attract Linux users by making the > environment more familiar to them. It was apparently assumed that > longtime Solaris users would quickly and easily figure out what the > problem was and adjust the PATH to their liking. >Well, it''s OpenSOLARIS, comes with nice OpenSOLARIS goodies. Oooh ZFS ACL! <rub hands together> Goody! chmod A+user... <gets slapped> ls -V <gets slapped> OpenSOLARIS sucks! It''s a quibble, but the way things are, it pleases no one, I don''t think the casual Linux user moseying over to OpenSolaris would like the scenario above. CT
Christine Tran wrote:>> There was a very long discussion about this a couple of weeks ago on >> one of the lists. Apparently the decision was made to put the GNU >> utilities in default system wide path before the native Sun utilities >> in order to make it easier to attract Linux users by making the >> environment more familiar to them. It was apparently assumed that >> longtime Solaris users would quickly and easily figure out what the >> problem was and adjust the PATH to their liking. >> > > Well, it''s OpenSOLARIS, comes with nice OpenSOLARIS goodies. Oooh ZFS > ACL! <rub hands together> Goody! chmod A+user... <gets slapped> ls > -V <gets slapped> OpenSOLARIS sucks! > > It''s a quibble, but the way things are, it pleases no one, I don''t > think the casual Linux user moseying over to OpenSolaris would like > the scenario above.As a previous long-time linux user who came over for ZFS, I totally agree. I much preferred to learn the solaris way and do things right than try and think it was still linux. Now I''m comfortable working on both despite their differences, and I''m sure I can perform tasks a lot better for it. Matt
Yeah, breaking functionality in one of the main reasons people are going to be trying OpenSolaris is just dumb... really, really dumb. One thing Linux, Windows, OS/X, etc all get right is that they''re pretty easy to use right out of the box. They''re all different, but they all do their own jobs pretty well. So what do Sun do, make OpenSolaris harder to use... -- This message posted from opensolaris.org
On 29-Jan-09, at 2:17 PM, Ross wrote:> Yeah, breaking functionality in one of the main reasons people are > going to be trying OpenSolaris is just dumb... really, really dumb. > > One thing Linux, Windows, OS/X, etc all get right is that they''re > pretty easy to use right out of the box. They''re all different, > but they all do their own jobs pretty well. So what do Sun do, > make OpenSolaris harder to use...I''ve not used OpenSolaris (yet), but I did spend quite a bit of time in Solaris 10 after using Linux and OS X for a long time. Matt''s approach does work. Learn the differences, don''t resent that they''re the same, and get comfortable in both. Given the massive success of GNU based systems (Linux, OS X, *BSD) one can hardly fault OpenSolaris for taking this direction (I assume this is part of Ian Murdock''s brief to make it a more appealing O/S option). Maybe Sun needs to make this optional, leaving the traditional SYSV flavour for the kneejerk anti-GNU elements (a bizarre phenomenon given SunOS'' pure open source genesis ... Berkeley, Bill Joy, BSD, yadda yadda). --Toby> -- > This message posted from opensolaris.org > _______________________________________________ > zfs-discuss mailing list > zfs-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
> Given the massive success of GNU based systems (Linux, OS X, *BSD)Ouch! Neither OSX nor *BSD are GNU-based. They do ship with GNU-related things but that''s been a long and hard battle. And the massive success has really only been Linux due to brilliant PR (and FUD about *BSD) and OS X due to Apple''s commercial approach to BSD. Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Sun Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 45 Gesch?ftsf?hrer: Rainer J. H. Brandt und Volker A. Brandt
Volker A. Brandt wrote:>> Given the massive success of GNU based systems (Linux, OS X, *BSD) >> > > Ouch! Neither OSX nor *BSD are GNU-based.Not here, please. This topic has been beaten to death on the discuss list, where it''s topical. -- Ian.
>>>>> "fm" == Fredrich Maney <fredrichmaney at gmail.com> writes:fm> put the GNU utilities in default system wide path before the fm> native Sun utilities in order to make it easier to attract fm> Linux users It''s a quick thing to make it feel like you''re ``doing something about the problem'''' but the idea of different users having different PATHs feels awkward to a Linux user, too. If you must have multiple versions, not defaulting to the most obsolete version then forcing users to carefully request the newest standards-compliant one if they really really ``need'''' it, is a step in the right direction. So is including source for the default, maintained version of the tool instead of adding fancy ACL stuff to the old closed-source tool. I''m not sure the modern, open tool necessarily has to be a GNU tool to make this Linux user happy. Just needs to be other than some ancient piece-of-junk no-source tool that you keep around with the mealy powerless excuse ``we don''t want to break some obtuse shell script installer of abandoned expensive proprietary software.'''' What makes me really uncomfortable as a Linux user, is the mess of silly assertions, simon-sez flags, and tool proliferation around writing disk labels. It seems impossible to build a normal iSCSI target out of Solaris because there''s no way to write to an unlabeled disk. It goes nuts if the initiator writes a new label onto the target? Also all the binary config files containing secret information that can''t be completely inspected, and can be transformed only by some assertion-riddled tool, not arbitrarily. The lack of a one-stop spot to pull state information out of the kernel without blocking or panicing like you get with Linux''s /proc. finally, the unfree toolchain. Except for the last, these things have all bitten ZFS users in particular. Linux users properly recognize these points as good architectural decisions about which their camp has driven a stake into the ground, and they''re unlikely to relay their tent because you call them partisan or NIH or closed-minded. The wise Linux user isn''t looking for pandering immitation. He''s looking for evidence that good lessons from what Linux has done right are making their way into Solaris, just as they''ve made their way into BSD and even Windows. I grant that it''s a bit prejudiced of the Linux camp to view every platform other than their own as ``stagnant until proven otherwise,'''' but you have to admit there''s SOME truth, even in that. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 304 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090129/a9e3e25c/attachment.bin>
On 29-Jan-09, at 4:53 PM, Volker A. Brandt wrote:>> Given the massive success of GNU based systems (Linux, OS X, *BSD) > > Ouch! Neither OSX nor *BSD are GNU-based.I meant, extensive GNU userland (in OS X''s case). (sorry Ian) --Toby> They do ship with > GNU-related things but that''s been a long and hard battle. > > And the massive success has really only been Linux due to brilliant > PR (and FUD about *BSD) and OS X due to Apple''s commercial approach > to BSD. > > > Regards -- Volker > -- > ---------------------------------------------------------------------- > -- > Volker A. Brandt Consulting and Support for Sun > Solaris > Brandt & Brandt Computer GmbH WWW: http://www.bb- > c.de/ > Am Wiesenpfad 6, 53340 Meckenheim Email: vab at bb- > c.de > Handelsregister: Amtsgericht Bonn, HRB 10513 > Schuhgr??e: 45 > Gesch?ftsf?hrer: Rainer J. H. Brandt und Volker A. Brandt
"Volker A. Brandt" <vab at bb-c.de> wrote:> > Given the massive success of GNU based systems (Linux, OS X, *BSD) > > Ouch! Neither OSX nor *BSD are GNU-based. They do ship with > GNU-related things but that''s been a long and hard battle.While you are true, this isn''t going to help on. Let me try to give some new input.... I see three possible types of Linux users that should be discussed. 1) The really dumb Linux users. These people will not notice that they are using the Solaris/UNIX userland instead of the GNU userland. So why by default put /usr/gnu/bin in front for them? 2) The trolls. They are a small group but very active with publishing their "opinion" in the net. Do we really need or like to suport them? 3) The educated/smart Linux users. They know about the differences and they are able to decide whether they like to use the Solaris tools with full Solaris feature support by default or whether their default PATH should habe /usr/gnu/bin first. So why by default put /usr/gnu/bin in front for them? J?rg -- EMail:joerg at schily.isdn.cs.tu-berlin.de (home) J?rg Schilling D-13353 Berlin js at cs.tu-berlin.de (uni) joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
> > Ouch! Neither OSX nor *BSD are GNU-based. They do ship with > > GNU-related things but that''s been a long and hard battle. > > While you are true, this isn''t going to help on.I agree.> I see three possible types of Linux users that should be discussed. > > 1) The really dumb Linux users. These people will not notice that > they are using the Solaris/UNIX userland instead of the GNU userland. > So why by default put /usr/gnu/bin in front for them?Hmmm... I don''t think a Linux user can be "really dumb". He/she would not run Linux, but a certain other system. :-)> 2) The trolls. They are a small group but very active with publishing > their "opinion" in the net. > Do we really need or like to suport them? > > 3) The educated/smart Linux users. They know about the differences > and they are able to decide whether they like to use the Solaris > tools with full Solaris feature support by default or whether > their default PATH should habe /usr/gnu/bin first. > So why by default put /usr/gnu/bin in front for them?I think only the third group of people are really interested in trying out Solaris/OpenSolaris. So it''s really a toss-up: Linux types can be expected to fix up their path; so can we Solaris types. But as others have rightly pointed out this discussion should really take place on some advocacy list. Regards -- Volker -- ------------------------------------------------------------------------ Volker A. Brandt Consulting and Support for Sun Solaris Brandt & Brandt Computer GmbH WWW: http://www.bb-c.de/ Am Wiesenpfad 6, 53340 Meckenheim Email: vab at bb-c.de Handelsregister: Amtsgericht Bonn, HRB 10513 Schuhgr??e: 45 Gesch?ftsf?hrer: Rainer J. H. Brandt und Volker A. Brandt
On Fri, Jan 30, 2009 at 3:55 AM, Volker A. Brandt <vab at bb-c.de> wrote:> > > Hmmm... I don''t think a Linux user can be "really dumb". He/she would > not run Linux, but a certain other system. :-)My mother just ordered a netbook that came with ubuntu. She can barely handle turning a system on. So there most definitely are "really dumb" linux users. Not to say she isn''t an intelligent person, but she definitely is a "dumb user" (SORRY MOM!).> > > > 2) The trolls. They are a small group but very active with publishing > > their "opinion" in the net. > > Do we really need or like to suport them? > > > > 3) The educated/smart Linux users. They know about the differences > > and they are able to decide whether they like to use the Solaris > > tools with full Solaris feature support by default or whether > > their default PATH should habe /usr/gnu/bin first. > > So why by default put /usr/gnu/bin in front for them? > > I think only the third group of people are really interested in > trying out Solaris/OpenSolaris. So it''s really a toss-up: Linux > types can be expected to fix up their path; so can we Solaris types. > > But as others have rightly pointed out this discussion should really > take place on some advocacy list. >Of course, but it does help to generate some discussion within the various projects full of people who don''t subscribe or really care about the advocacy list but are directly affected by their decisions. It''s far easier for someone to say "here, look at this discussion" than to say "I promise, there''s a bunch of people who really want this, they just don''t subscribe to this list". --Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090130/ee2709a6/attachment.html>
On Fri, Jan 30, 2009 at 9:24 AM, Tim <tim at tcsac.net> wrote:> On Fri, Jan 30, 2009 at 3:55 AM, Volker A. Brandt <vab at bb-c.de> wrote:[...]>> > 3) The educated/smart Linux users. They know about the differences >> > and they are able to decide whether they like to use the Solaris >> > tools with full Solaris feature support by default or whether >> > their default PATH should habe /usr/gnu/bin first. >> > So why by default put /usr/gnu/bin in front for them? >> >> I think only the third group of people are really interested in >> trying out Solaris/OpenSolaris. So it''s really a toss-up: Linux >> types can be expected to fix up their path; so can we Solaris types. >> >> But as others have rightly pointed out this discussion should really >> take place on some advocacy list. > > Of course, but it does help to generate some discussion within the various > projects full of people who don''t subscribe or really care about the > advocacy list but are directly affected by their decisions. It''s far easier > for someone to say "here, look at this discussion" than to say "I promise, > there''s a bunch of people who really want this, they just don''t subscribe to > this list".I don''t think I have ever subscribed to an advocacy list in my life. If important decisions like changing the default toolset for the next version for the OS are only discussed there, I''d never know about them until they were implemented - and that would result in a lot of very annoyed calls to support and my Account Manager expressing my displeasure over. Chasing the Linux crowd at the expense of the long term Solaris base makes no sense. That holds true whether it is shelving and torpedoing Solaris x86 in order to please non-technical "analysts" on Wall Street who think that in order to survive as a business that you "must have a linux solution", or changing the default toolset (without notification) from the expected native tools to external tools in order to "make OpenSolaris more user friendly and familiar to the Linux crowd". fpsm
>>>>> "fm" == Fredrich Maney <fredrichmaney at 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. 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. 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. 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 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. I don''t care if the default tools are Linux tools or not, but the default tools should be the newest ones not the oldest ones as they are now, should not be bit-rotted, should work somewhat well with other systems, and should come with source. If the legacy tools can be made to do this by people who love them, I think that''s great, but if they cannot, then ad-hominem attacks and vendor-pandering should not stonewall those reasonable expectations of openness, development, and interoperability, because they are *necessary for survival*, and they are not Linux-pandering. And being the Default tool doesn''t just mean coming first in PATH. It means, when you add some new filesystem ACL framework, you add it to the Default tool. I think the real mistake is imagining there are enough users and developers on the boat for people to ``choose'''' the ``feel'''' of their environment. It''s better to make some screaming NIH people unhappy and have _one_ system that works well. That''s the real opportunity to surpass Linux IMHO because sometimes things over there do not work well. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 304 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090130/1cd37e7f/attachment.bin>
On Fri, Jan 30, 2009 at 1:19 PM, Miles Nordin <carton at ivy.net> wrote:>>>>>> "fm" == Fredrich Maney <fredrichmaney at 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
>>>>> "fm" == Fredrich Maney <fredrichmaney at gmail.com> writes:fm> Oddly enough, that seems to be the path was taken by fm> Sun quite some time ago with /usr/bin. Those tools are the fm> standard, default tools on Sun systems for a reason: they are fm> the ones that are maintained and updated with new features nope. The tools in xpg4 and xpg6 have more features and are more updated. For example, ls recently got -% option. This seems to work for /usr/bin/ls, /usr/xpg4/bin/ls, and /usr/xpg6/bin/ls. so, that''s good! albeit a little surprising. But if /usr/xpg6/bin/ls came first in PATH, it would make sense to save effort by adding the -% to the newest ls only. Scripts which rely on some bug in older ls, will not know about -% all for viewing ZFS ctime, and not benefit from it. I imagine some broken scripts hardcoded the full path to /usr/bin/ls which some from the Solaris tent took to mean that /usr/bin/ls can never do anything more than what those ancient scripts expect. This is bogus! COMPAT environments belong in a zone. Alternatively, just let the script break. And if the GNU tools are default, they should get -% and any other ZFS feature, and get it first. Whatever tools are default should not be left out of the main thrust of development. Certainly Linux gets this right. Even before adding any GNU stuff Solaris got it wrong. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 304 bytes Desc: not available URL: <http://mail.opensolaris.org/pipermail/zfs-discuss/attachments/20090202/29cbdbf1/attachment.bin>
>For example, ls recently got -% option. This seems to work for >/usr/bin/ls, /usr/xpg4/bin/ls, and /usr/xpg6/bin/ls. so, that''s good! >albeit a little surprising.There''s only one source file. So if you add an option you''ll add it to all of them.>But if /usr/xpg6/bin/ls came first in PATH, it would make sense to >save effort by adding the -% to the newest ls only. Scripts which >rely on some bug in older ls, will not know about -% all for viewing >ZFS ctime, and not benefit from it. > >I imagine some broken scripts hardcoded the full path to /usr/bin/ls >which some from the Solaris tent took to mean that /usr/bin/ls can >never do anything more than what those ancient scripts expect. This >is bogus! COMPAT environments belong in a zone. Alternatively, just >let the script break.Adding a new option is fine; changing the output is not. Casper