Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
Ken Gunderson wrote: > > Interesting that you should mention OpenBSD. A buddy of mine (very > experienced Unix grey-beard) just did exactly that. Happy as a clam, > that he did. What's not on OBSD, bigger iron needs, he's running AIX. > > He spent a lot of time trying to convince me that Solaris would be a bad > move. Nevertheless, after some weeks of discussion and playing around a > bit, I decided to buck his advice and at least employ as development > platform for next upcoming project, and see how things went for > there. I could be wrong, but recent discussions here are giving a > lot of second thoughts stemming the distinct impression that > Open/Solaris is trying to morph into another Linux-esque system in > efforts to be popular. Well, hey, I could have been really, really > popular in high school if I would have been doing a lot of drugs, but > that still didn't make it a good idea. > > There's a big difference between what's under the hood (the kernel) and what goes on in userland. These waste of bandwidth threads pop up here from time to time, but if you want to see what's really going on, have a look at the more specialised lists. Ian ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
On Wed, 06 Feb 2008 20:44:26 PST "Dr. Robert Pasken" <[EMAIL PROTECTED]> wrote: > To make sure you understand. I started with a PDP-11/45, an rm-03, a tu-66 > and Unix V7. My current home computer is a Sun Ultra-24 which has SUSE-10, > Ubuntu Hardy-Heron and Solaris-10 installed. I don't care for Ubuntu's "we > know more than you do" installation and packaging system.I don't care if the > installation process looks pretty or is "easy", I should only install just > once. The packaging system shouldn't force me to do a bare metal install > because patching one package results in every other package breaking. I don't > care for the community flame wars over "eye-candy". I do not care if this > weeks newest webcam works or if I can play music from iTunes. What I do care > about is if I can find away to shave another 10 minutes off WRF and MM5 > model run times with 4 cores and 8gb of memory. Can I get HYSPLIT_4 to > generate explosion plumes while WRF is running at the same time. Can I volume > render HYSPLIT_4 output on a laptop. While Linux is more stable Windows, > Linux has be en > and is moving in the direction of "eye-candy" and reduced stability. This > based on real-world experience. I cann't afford more file-system failures or > kernel crashes while WRF/HYSPLIT/DRAS is running. I will abandon Solaris and > move to OpenBSD if Solaris moves to the Linux model. > Interesting that you should mention OpenBSD. A buddy of mine (very experienced Unix grey-beard) just did exactly that. Happy as a clam, that he did. What's not on OBSD, bigger iron needs, he's running AIX. He spent a lot of time trying to convince me that Solaris would be a bad move. Nevertheless, after some weeks of discussion and playing around a bit, I decided to buck his advice and at least employ as development platform for next upcoming project, and see how things went for there. I could be wrong, but recent discussions here are giving a lot of second thoughts stemming the distinct impression that Open/Solaris is trying to morph into another Linux-esque system in efforts to be popular. Well, hey, I could have been really, really popular in high school if I would have been doing a lot of drugs, but that still didn't make it a good idea. -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Wed, 6 Feb 2008 15:55:07 -0600 "Shawn Walker" <[EMAIL PROTECTED]> wrote: > On Feb 6, 2008 3:37 PM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > > Shawn Walker wrote: > > > On Feb 6, 2008 3:18 PM, a b <[EMAIL PROTECTED]> wrote: > > > > > > Oh, and as far as the enterprise argument, go talk to some of the > > > enterprise sysadmins who post here; they hate that /bin/sh isn't > > > anywhere near portable across systems. > > > > > > > > It's also not part of any standard, so how could it really? > > That doesn't excuse having a good standard shell for /bin/sh. > > > If they want to write portable scripts they should use /bin/ksh. It's > > that simple. > > They're not the ones who wrote the scripts from what I gather. They > are the ones trying to use software across multiple systems. > > At least with a POSIX shell for /bin/sh, there is a far better chance > of getting scripts written by third parties to work. Shawn: Do you have any actual enterprise systems admin experience? And if so, I'd be curious as to what platforms. Or is your role more primarily along the lines of Open/Solaris evangelist? Just curious so I can understand where you're coming from a bit better. In my opinion /bin/sh should be /bin/sh (bourne), no if's ands or buts about it. Even casual newbie script writer knows to specify the "she-bang" shell at start of script. That's what provides consistent behavior. The portability across platforms issue arise because platform A may put ksh93 in /usr/local/bin/ksh93, while platform B has it in /bin/ksh93, etc. There are common workarounds for this type of issue that have been around for decades. root's login shell is another matter. cron, scripts, etc. should specify the shell. changing root's default shell to ksh93 is just fine with me, e.g. see me earlier post w.r.t. OpenBSD, as long as you label it ksh93, and not try to rebadge as /bin/sh because then us sysadmin types think we're dealing with bourne shell. Make is zsh, or xyzsh if you want, but don't call something that's not /bin/sh because that's when you're setting the stage for disaster. OTOH, leaving it as /bin/sh is no big deal either, since under most situations admins will be su'ing up from mortal account and can carry whatever their preferred shell with them when they do. Granted in rare instances where one must login as root in single user mode it's nice to have a decent interactive shell, but not at expense of screwing over the "old guard". And these days where less of the system and userland files are being broken out onto separate partitions, it's becoming more and more of a corner case. Thank you and have a nice day. -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Installing Development Tools from SXDE 01/08
> In the cd, there is a folder by name DeveloperTools. > Run > INSTALL_DEVTOOLS.SH script. > Thanks. Done. However, got the following warning message: # ./install_devtools.sh Warning: Cannot convert string "-dt-interface user-medium-r-normal-s*utf*-*-*-*-*-*-*-*-*" to type FontStruct # This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Installing Development Tools from SXDE 01/08
In the cd, there is a folder by name DeveloperTools. Run INSTALL_DEVTOOLS.SH script. W. Wayne Liauh wrote: > I used the old installer in SXDE4 (01/08). As a result, the development > tools are not installed. > > I remember there is a simple script to install all those development tools > from the SXDE DVD. Can someone tell me what that is? Thanks. > > Also, does any one know when the new installer will allow multi-boot with > other Solaris slices? Thanks again. > > > This message posted from opensolaris.org > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
To make sure you understand. I started with a PDP-11/45, an rm-03, a tu-66 and Unix V7. My current home computer is a Sun Ultra-24 which has SUSE-10, Ubuntu Hardy-Heron and Solaris-10 installed. I don't care for Ubuntu's "we know more than you do" installation and packaging system.I don't care if the installation process looks pretty or is "easy", I should only install just once. The packaging system shouldn't force me to do a bare metal install because patching one package results in every other package breaking. I don't care for the community flame wars over "eye-candy". I do not care if this weeks newest webcam works or if I can play music from iTunes. What I do care about is if I can find away to shave another 10 minutes off WRF and MM5 model run times with 4 cores and 8gb of memory. Can I get HYSPLIT_4 to generate explosion plumes while WRF is running at the same time. Can I volume render HYSPLIT_4 output on a laptop. While Linux is more stable Windows, Linux has been and is moving in the direction of "eye-candy" and reduced stability. This based on real-world experience. I cann't afford more file-system failures or kernel crashes while WRF/HYSPLIT/DRAS is running. I will abandon Solaris and move to OpenBSD if Solaris moves to the Linux model. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Installing Development Tools from SXDE 01/08
I used the old installer in SXDE4 (01/08). As a result, the development tools are not installed. I remember there is a simple script to install all those development tools from the SXDE DVD. Can someone tell me what that is? Thanks. Also, does any one know when the new installer will allow multi-boot with other Solaris slices? Thanks again. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 5:38 PM, Shawn Walker <[EMAIL PROTECTED]> wrote: > On Feb 6, 2008 2:36 PM, Ken Gunderson <[EMAIL PROTECTED]> wrote: > > On Wed, 6 Feb 2008 14:12:59 -0600 > > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > > On Feb 6, 2008 1:16 PM, Joerg Schilling > > > <[EMAIL PROTECTED]> wrote: > > > > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > > > > > > > Compared to bash, /bin/sh (the Burne Shell) is bug-free. > > > > > > > > > > I don't think you'll find many users that agree. > > > > > > > > This is because most bash users don't understand POSIX nor > > > > care about bugs. They are not even interested in knowing the > > > > reason for a problem. > > > > > > Exactly! So why not give them a shell that is POSIX and that is full > > > featured and provides something that makes them feel much more at > > > home. > > > > > > > s/them/Linuxers/g > > No; s/them/almost any other users that don't use Solaris/ > > Seriously; FreeBSD, NetBSD, OpenBSD, GNU/Linux, and many others all > provide a better /bin/sh... > what we really need is a way for users to change their own shells without root privileges in /etc/passwd why would you want to change /bin/sh possibly breaking thousands of scripts many of which are critical and can't be changed? because you want something that is a better interactive shell? there are many of them already, zsh, bash, ksh93 and as a user you can pick any of them as a rule i leave my root using /bin/sh but you can easily use RBAC to create a root like user with a different shell nacho ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] zfs send/receive between different releases
Hello everybody, I'm thinking of building out a second machine as a backup for our mail spool where I push out regular filesystem snapshots, something like a warm/hot spare situation. Our mail spool is currently running snv_67 and the new machine would probably be running whatever the latest opensolaris version is (snv_77 or later). My first question is whether or not zfs send / receive is portable between differing releases of opensolaris. My second question is that I was wondering the difficulty involved in upgrading snv_67 to a later version of opensolaris given that we're running a zfs root boot configuration -- Michael Hale<[EMAIL PROTECTED] > Manager of Engineering Support Enterprise Engineering Group Transcom Enhanced Services http://www.transcomus.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: > On Feb 6, 2008 3:37 PM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > >> Shawn Walker wrote: >> >>> On Feb 6, 2008 3:18 PM, a b <[EMAIL PROTECTED]> wrote: >>> >>> Oh, and as far as the enterprise argument, go talk to some of the >>> enterprise sysadmins who post here; they hate that /bin/sh isn't >>> anywhere near portable across systems. >>> >>> >>> >> It's also not part of any standard, so how could it really? >> > > That doesn't excuse having a good standard shell for /bin/sh. > > What reason is there for the 'standard' shell to be named /bin/sh though? When there is a standards compliant shell at another name that will work, >> If they want to write portable scripts they should use /bin/ksh. It's >> that simple. >> > > They're not the ones who wrote the scripts from what I gather. They > are the ones trying to use software across multiple systems. > > Trying to use software on a system other than what the developer intended is asking for problems. Obviously the developer didn't test it on these other platforms either. Given that there is no standard for how /bin/sh should work, it's possible that those scripts even take advantage of non-standard differences of the /bin/sh, and that they still won't work on strictly POSIX compliant /bin/sh that doesn't also emulate the other behaviors of the /bin/sh sheel they written for. If these scripts will magically start working when /bin/sh is ksh93 (which I doubt) then they'll also start working if the users edit them to start with #!/bin/ksh. And sinve that is (more?) standards compliant, that should still work on the platforms the scripts already work on. Is the bourne shell old? Yes. Are different implementations of the Bourne Shell incompatible? Yes. But also: Is /bin/sh the tradition location/name of the Bourne Shell? Yes. Platforms should feel free to stop including a /bin/sh altogether. There's no reason to have one if you don't want one. But what they replace it with shouldn't be called /bin/sh unless it is. > At least with a POSIX shell for /bin/sh, there is a far better chance > of getting scripts written by third parties to work. > > Only if they were written to only use strictly POSIX syntax. And if that's the case then they should also wrtie tehm to use the things the POSIX standard specifies in order to find the POSIX shell they want to run in. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Shell Compatibility was Re: [osol-announce] No update on SXCE Build 79
"Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > It isn't a wild guess. If I'm not mistaken, Roland has been doing some > > > testing and work in the area of shell compatibility. > > > > Please read the rest of the mail you replied to and you understand why it > > would > > not work. > > Since you're not trying to solve the problem, but merely trying to > keep the problem from trying to be solved, I have a hard time > believing you. You are not going to solve a problem, you are going to create new problems instead Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] on/downloads/current/ restored
Al Hopper wrote: > On Tue, 5 Feb 2008, Derek Cicero wrote: > >> It looks like: >> >> http://dlc.sun.com/osol/on/downloads/current/ If you dump your cache /current/ should give you the 20080129 bits. Overall, the current status is as follows: The restore done yesterday is complete (it came from 2/1) and they are currently setting all the correct permissions/ownerships on the files. We are still in read-only mode for now (meaning we can't do a push from our staging machine) as they do a final verification of the data. Once the final verification is complete and we will do a push from our staging server to sync/pick up any missing bits from 2/1 or later. btw - Our team does not actually own the DLC machines so we are working with the group that owns them to get all this restored, but I have limited visibility into what is going on. Apologies. Derek > > Not yet! Take a look at some of the files in downloads/current/. > They use a naming convention that includes the date in a format like > mmdd - even in the title: "ON (OS/Net) Consolidation - 20080129". > Also, take a look at some of the filenames, for example, > "on-changelog-20071001.html" which includes the mmdd component. > And BTW, the directory "current" does not point to the latest > available release. > > Now the site has been reloaded with a structure that existed earlier > (around b62 IIRC). For example, in directory b82 the title is now: > "ON (OS/Net) Consolidation - b82" and the files don't use a mmdd > component, instead they use the consolidation "b" number. For > example: "on-changelog-b82.html". > > I don't think it matters which filenaming convention you follow, but I > would like it to remain *constant* over time. Hmm.. the "bnn" format > looks a little cleaner IMHO. > >> Has been restored, but I am still waiting for official notification that >> it's completely in sync. >> > > Regards, > > Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED] > Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT > OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007 > http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/ > ___ > opensolaris-discuss mailing list > opensolaris-discuss@opensolaris.org > -- Derek Cicero Program Manager Solaris Kernel Group, Software Division ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Shell Compatibility was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 3:33 PM, Joerg Schilling <[EMAIL PROTECTED]> wrote: > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > On Feb 6, 2008 2:57 PM, Joerg Schilling > > <[EMAIL PROTECTED]> wrote: > > > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > (Or you need to proof that there are no /bin/sh scripts in use on > > > > > Solaris > > > > > which execute differently under ksh/ksh93) > > > > > > > > ...ksh93 can be modified to provide backwards compatibility where > > > > possible. > > > > > > > > > This is not true, at least not if you limit the effort to reasonable > > > values... > > > > > > Your wild guess seems to be a result of not knowing why e.g. these > > > commands > > > > It isn't a wild guess. If I'm not mistaken, Roland has been doing some > > testing and work in the area of shell compatibility. > > Please read the rest of the mail you replied to and you understand why it > would > not work. Since you're not trying to solve the problem, but merely trying to keep the problem from trying to be solved, I have a hard time believing you. I will have to agree to disagree. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 3:37 PM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > Shawn Walker wrote: > > On Feb 6, 2008 3:18 PM, a b <[EMAIL PROTECTED]> wrote: > > > > Oh, and as far as the enterprise argument, go talk to some of the > > enterprise sysadmins who post here; they hate that /bin/sh isn't > > anywhere near portable across systems. > > > > > It's also not part of any standard, so how could it really? That doesn't excuse having a good standard shell for /bin/sh. > If they want to write portable scripts they should use /bin/ksh. It's > that simple. They're not the ones who wrote the scripts from what I gather. They are the ones trying to use software across multiple systems. At least with a POSIX shell for /bin/sh, there is a far better chance of getting scripts written by third parties to work. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Lessons from elsewhere, was Re: [osol-announce] No update on SXCE Build 79
> I'm familiar with it. A shining example of how not to do it. I know you're "familiar" with it. And that it's your favorite. I actually "dove a little deeper", and have done quite a few tardists. You know what those are? And I can say with confidence that the engineers which came up with inst(1M) are freaking geniouses. If I were their fan, I would be bowing down before those gurus at least three times a day. If I were. How can I claim that? Well, I happen to do system V packages almost every day. You know, the SUNW-quality kind. And I also do tons, and tons, and then some more, of SD-UX product packaging for HP-UX. So I'm kind of in a unique position to say which packaging system has which strengths and which weaknesses. And I'm telling you: inst(1M) is simply phenomenal. The only technical weakness in inst(1M) was a namespace identifier, a numerical identifier, similar to a counter, which expired on a May 17th, 200x (don't remember which any more). sgi was fixing it, but I don't rightly know how that ended. Other than that, inst(1M) was perfect. > Something capable of tangling your installed software into > such a convoluted set of intertwined dependencies that it > was then completely incapable of adding or removing anything. It seems to me, you missed something along the way. > Anything else? Sure. All of techpubs.sgi.com? Care to take your pick? _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: > On Feb 6, 2008 3:18 PM, a b <[EMAIL PROTECTED]> wrote: > > Oh, and as far as the enterprise argument, go talk to some of the > enterprise sysadmins who post here; they hate that /bin/sh isn't > anywhere near portable across systems. > > It's also not part of any standard, so how could it really? If they want to write portable scripts they should use /bin/ksh. It's that simple. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
"Shawn Walker" <[EMAIL PROTECTED]> wrote: > > If you like to have an acceptable workaround for the ill-designed IBM-PC > > keyboard, you should use "rxvt" or the "gnome terminal". This will give you > > the expected "DEL" character from the key at the mechanical position of the > > "delete key". > > > > If you like to see the incorrect backspace behavior of bash, use bash. > > If Solaris is going to remain commercially viable, it must transform and > adopt. Why should Solaris implement bugs from bash? Do you really believe Solaris would _gain_ from implementing bugs? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
"Shawn Walker" <[EMAIL PROTECTED]> wrote: > On Feb 6, 2008 2:57 PM, Joerg Schilling > <[EMAIL PROTECTED]> wrote: > > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > > > > > > > (Or you need to proof that there are no /bin/sh scripts in use on > > > > Solaris > > > > which execute differently under ksh/ksh93) > > > > > > ...ksh93 can be modified to provide backwards compatibility where > > > possible. > > > > > > This is not true, at least not if you limit the effort to reasonable > > values... > > > > Your wild guess seems to be a result of not knowing why e.g. these commands > > It isn't a wild guess. If I'm not mistaken, Roland has been doing some > testing and work in the area of shell compatibility. Please read the rest of the mail you replied to and you understand why it would not work. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Lessons from elsewhere, was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 9:23 PM, a b <[EMAIL PROTECTED]> wrote: > > > On Feb 6, 2008 9:37 AM, a b <[EMAIL PROTECTED]> wrote: > > > > > > IRIX may be dead, but if we consider that IRIX, even though it is dead, > > > still has in it technology that is light years ahead of anything currently > > > available on the market, you ought to sit down and really rethink the > > > statement you made above. > > > > > > Especially if we consider that IRIX still has technology that puts "the > > > most > > > advanced operating system on the planet" to shame, > > > > Care to give some examples? > > Indeed I can, your "favorite": inst(1M) I'm familiar with it. A shining example of how not to do it. Something capable of tangling your installed software into such a convoluted set of intertwined dependencies that it was then completely incapable of adding or removing anything. Anything else? -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
> > And you don't have to be; that'll change all by itself as you gain > > engineering experience under your belt. > > Such a statement incorrectly assumes that I do not have such experience. If you did actually posess the necessary experience, we wouldn't be having this discussion right now. Just as I don't need to discuss certain things with Casper. Or Joerg. Or James. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 3:27 PM, Joerg Schilling <[EMAIL PROTECTED]> wrote: > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > ANd giving them ksh (or even dash I imagine) on Solaris isn't going to > > > be that noticeable then, or any better. Theonly thing they'll > > > appreciate is giving them bash complete with it's bugs. > > > > A working backspace key isn't going to be noticed? > > Do you really like to "discuss" at a knowledge level of an average > Linux user? > > If you like to discuss these things, please first try to understand the > background. > > If you like to have an acceptable workaround for the ill-designed IBM-PC > keyboard, you should use "rxvt" or the "gnome terminal". This will give you > the expected "DEL" character from the key at the mechanical position of the > "delete key". > > If you like to see the incorrect backspace behavior of bash, use bash. If Solaris is going to remain commercially viable, it must transform and adopt. Some of those changes will be unpopular, but they are the right changes to make. People who enjoy a UNIX system that acts like a VT100 or pdp-11 after 30 years are welcome to keep it, the rest of us are ready to move on. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 3:18 PM, a b <[EMAIL PROTECTED]> wrote: > > > > Someone had the guts to stand up against the ultraconservative > > 'backwards compatibility is our religion' [EMAIL PROTECTED] > > Opensolaris cannot afford such Bourne shell extravaganza anymore > > You don't run many mission critical workloads on the server side of things, > do you? > > This ain't dustin' crops, > oh-look-at-me-I-managed-to-install-Linux-on-my-desktop-PC-bucket type of a > deal. > > Solaris is an enterprise grade desktop AND server operating system, and as > such, it *must* be able to take abuse as both a desktop and a server > operating system. > > What OpenSolaris can't afford is to become like Linux. That would be a > catastrophe for those of us that bring food on the table and pay the bills, > thanks in no small part to Solaris. > > Those who are just interested in geeking-off have toys like PC-buckets and > Linux, and it would seem that they're much better staying in that sandbox. > Em, I wish those lots of fun building sand castles, too. I'm not sure how ksh93 is making things like GNU/Linux. Oh, and as far as the enterprise argument, go talk to some of the enterprise sysadmins who post here; they hate that /bin/sh isn't anywhere near portable across systems. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 2:57 PM, Joerg Schilling <[EMAIL PROTECTED]> wrote: > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > > > > (Or you need to proof that there are no /bin/sh scripts in use on Solaris > > > which execute differently under ksh/ksh93) > > > > ...ksh93 can be modified to provide backwards compatibility where possible. > > > This is not true, at least not if you limit the effort to reasonable values... > > Your wild guess seems to be a result of not knowing why e.g. these commands It isn't a wild guess. If I'm not mistaken, Roland has been doing some testing and work in the area of shell compatibility. As I said before, where possible. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
"Shawn Walker" <[EMAIL PROTECTED]> wrote: > > ANd giving them ksh (or even dash I imagine) on Solaris isn't going to > > be that noticeable then, or any better. Theonly thing they'll > > appreciate is giving them bash complete with it's bugs. > > A working backspace key isn't going to be noticed? Do you really like to "discuss" at a knowledge level of an average Linux user? If you like to discuss these things, please first try to understand the background. If you like to have an acceptable workaround for the ill-designed IBM-PC keyboard, you should use "rxvt" or the "gnome terminal". This will give you the expected "DEL" character from the key at the mechanical position of the "delete key". If you like to see the incorrect backspace behavior of bash, use bash. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Lessons from elsewhere, was Re: [osol-announce] No update on SXCE Build 79
> On Feb 6, 2008 9:37 AM, a b <[EMAIL PROTECTED]> wrote: > > > > IRIX may be dead, but if we consider that IRIX, even though it is dead, > > still has in it technology that is light years ahead of anything currently > > available on the market, you ought to sit down and really rethink the > > statement you made above. > > > > Especially if we consider that IRIX still has technology that puts "the most > > advanced operating system on the planet" to shame, > > Care to give some examples? Indeed I can, your "favorite": inst(1M) Absolutely ingenious. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
> Someone had the guts to stand up against the ultraconservative > 'backwards compatibility is our religion' [EMAIL PROTECTED] > Opensolaris cannot afford such Bourne shell extravaganza anymore You don't run many mission critical workloads on the server side of things, do you? This ain't dustin' crops, oh-look-at-me-I-managed-to-install-Linux-on-my-desktop-PC-bucket type of a deal. Solaris is an enterprise grade desktop AND server operating system, and as such, it *must* be able to take abuse as both a desktop and a server operating system. What OpenSolaris can't afford is to become like Linux. That would be a catastrophe for those of us that bring food on the table and pay the bills, thanks in no small part to Solaris. Those who are just interested in geeking-off have toys like PC-buckets and Linux, and it would seem that they're much better staying in that sandbox. Em, I wish those lots of fun building sand castles, too. _ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
"Shawn Walker" <[EMAIL PROTECTED]> wrote: > On Feb 6, 2008 1:16 PM, Joerg Schilling > <[EMAIL PROTECTED]> wrote: > > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > > > Compared to bash, /bin/sh (the Burne Shell) is bug-free. > > > > > > I don't think you'll find many users that agree. > > > > This is because most bash users don't understand POSIX nor > > care about bugs. They are not even interested in knowing the > > reason for a problem. > > Exactly! So why not give them a shell that is POSIX and that is full > featured and provides something that makes them feel much more at > home. If you like to give them a POSIX shell, you definitely don't need to replace /bin/sh. People who don't write #!/bin/bash in their scripts, would even complain because they don't see the bash bugs in ksh93. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Lessons from elsewhere, was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 9:37 AM, a b <[EMAIL PROTECTED]> wrote: > > IRIX may be dead, but if we consider that IRIX, even though it is dead, > still has in it technology that is light years ahead of anything currently > available on the market, you ought to sit down and really rethink the > statement you made above. > > Especially if we consider that IRIX still has technology that puts "the most > advanced operating system on the planet" to shame, Care to give some examples? I've used and administered IRIX, and nothing immediately springs to mind. -- -Peter Tribble http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
"Josh Hurst" <[EMAIL PROTECTED]> wrote: > > 7, unfortunately, is not as it requires replacing /bin/sh with /bin/bash > > and that, I think, it something few would be willing to do. > > FYI Ubuntu uses dash as /bin/sh and Suse will use dash in the future. > ksh93 has been discussed but it needs to be licensed as LGPL or GPL > before Suse can use ksh93 as /bin/sh. Who has the missconception with licenses, it is suse or did you missunderstand things? Thanks to a long "fight" from David Korn "against" AT&T, ksh93 is under an approved "free" OpenSource license since ~ 5 years. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
"Shawn Walker" <[EMAIL PROTECTED]> wrote: > On Feb 6, 2008 1:10 PM, <[EMAIL PROTECTED]> wrote: > > 7, unfortunately, is not as it requires replacing /bin/sh with /bin/bash > > and that, I think, it something few would be willing to do. > > I don't see why 7 isn't an option, even if it does cause *some* degree > of break in compatibility. > > I think the problems caused by #!/bin/sh *not* being a decent shell > are greater than what little value there is in keeping it. It have been discussed many times in the POSIX mailing list and the result was always that #!/bin/sh is just outside the intentional scope pf POSIX because #!/bin/sh depends on a PATH name while POSIX _does_ _not_ deal with path names. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
"Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > (Or you need to proof that there are no /bin/sh scripts in use on Solaris > > which execute differently under ksh/ksh93) > > ...ksh93 can be modified to provide backwards compatibility where possible. This is not true, at least not if you limit the effort to reasonable values... Your wild guess seems to be a result of not knowing why e.g. these commands $ /sbin/sh -c 'foo=a; echo b | read foo; echo $foo' a $ /usr/bin/ksh93 -c 'foo=a; echo b | read foo; echo $foo' b give different results. It is a result of different concepts in the parser and interpreter for the shell syntax. sh executes pipes from left to right while ksh executes them from right to left, which results in "read foo" to be the foreground process on ksh and the background process with sh. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: > On Feb 6, 2008 2:35 PM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > >> Shawn Walker wrote: >> >>> On Feb 6, 2008 2:26 PM, Kyle McDonald <[EMAIL PROTECTED]> wrote: >>> >>> Shawn Walker wrote: > On Feb 6, 2008 1:16 PM, Joerg Schilling > <[EMAIL PROTECTED]> wrote: > > > >> "Shawn Walker" <[EMAIL PROTECTED]> wrote: >> >> >> >> Compared to bash, /bin/sh (the Burne Shell) is bug-free. >>> I don't think you'll find many users that agree. >>> >>> >>> >> This is because most bash users don't understand POSIX nor >> care about bugs. They are not even interested in knowing the >> reason for a problem. >> >> >> > Exactly! So why not give them a shell that is POSIX and that is full > featured and provides something that makes them feel much more at > home. > > > > How is that an 'Exactly!'??? If they don't understand what it means to be POSIX? and they don't care if there are bugs, or care why things are the way they are, How will they notice that you've given them these things they don't care or know enough to recognize? >>> They do care and they do recognize bugs and problems with Solaris /bin/sh. >>> >>> GNU/Linux users don't notice these issues with bash is what Joerg was >>> talking about. >>> >>> >>> >> ANd giving them ksh (or even dash I imagine) on Solaris isn't going to >> be that noticeable then, or any better. Theonly thing they'll >> appreciate is giving them bash complete with it's bugs. >> > > A working backspace key isn't going to be noticed? > > I was under the (possibly wrong) imporession that that was a terminfo, or other terminal definition problem. Not the shell. > Their programs suddenly working without requiring the shell scripts > for them to be changed isn't noticeable? > > And people who's programs ans shell scripts suddenly stop working won't be noticeable? Who's going to check all the scripts in the world and update them? Not just the scripts in solaris itself. Just think of all the Per or Post install or remove scripts in the packages in BlastWave, or aome other repository? What solaris user is going to be happy when they want to install VRTSvxfs pacakge and it fails? If you want to be able to write modern portable POSIX shellscripts then you should push for all the other UNIXes to have a /bin/ksh, and write your scripts with #!/bin/ksh With the exception of Linux (and you might be able to fix that for your machines with 'ln /bin/sh /bin/ksh' - I don't know.) I'm pretty sure the other unixes already have a decent ksh. -Kyle > Working locale support won't be noticed? > > Forgive me, but I think you don't realise just how broken /bin/sh is. > > How will it make them more at home? >>> A modern shell, such as ksh93, has functionality and locale support >>> that is near equivalent or superior to bash. >>> >>> >>> >> But if they don't care, why would they notice? >> > > They do care and do notice. > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Software Change was Re: [osol-announce] No update on SXCE Build 79
On Wed, 06 Feb 2008 12:19:46 -0800 Alan Coopersmith <[EMAIL PROTECTED]> wrote: > Ken Gunderson wrote: > > On Wed, 06 Feb 2008 10:46:54 -0800 > > Alan Coopersmith <[EMAIL PROTECTED]> wrote: > >> Kyle McDonald wrote: > >> The missing link here is deciding it's worthwhile to do that work. > >> When xscreensaver was added to Solaris during one of the Solaris 9 > >> update releases it was explicitly to provide a screensaver for the > >> GNOME 2.0 desktop.Making it depend on GTK+ was a goal of that > >> work - making it installable without any GNOME libraries was not, > >> and is still not a goal today for those at Sun paid to do this work. > > > > "Making it depend on GTK+ was a goal of that work" > > > > Wow!! That's some extrordinarily bizarre goal setting there... > > Assumption that anyone running X will _also_necessarily want to be > > dependent on Gnome. Now to say that you're too lazy to separate the > > two is one thing, but to pass off as a "featured goal" is quite > > another, imho. I can imagine how the KDE4 integration team is feeling > > about that (just as one example from w/in Sun itself). > > Only if you make the assumption that anyone running X but not running GNOME > will want to run the xscreensaver we built for GNOME integration - I > certainly don't assume that, and you can easily run X without it. > > Sun's goal at the time was to deliver a GNOME desktop that met the > requirements of the US Government Section 508 regulations on Accessibility. > The interfaces available to meet that were GTK+ or Java Swing, so GTK+ was > chosen to reduce the change to porting the unlock dialog to a new toolkit > instead of porting to an entire new language & runtime environment. > > Since Sun was only shipping CDE & GNOME, and CDE already had a screen lock, > and Solaris already had xlock for other desktops, xscreensaver was not > viewed as a generic X desktop feature, but part of the GNOME desktop. > > There's nothing stopping anyone who wants to build their own desktop, such > as KDE, from building their own xscreensaver using another toolkit, or > xlockmore or another screen lock, or even using the Solaris provided xlock. > Of course, if they want xscreensaver to not use GTK+ at all, they'll also be > forking from upstream, since jwz (the upstream maintainer) has chosen GTK+ > as the toolkit for the preferences interface, while he does not use it for > the unlock dialog as we do. Thanks for the background information. I'll amend to a bit less bizarre... there is delicate balance between not reinventing the wheel and minimizing 3rd party dependencies. Both are important. -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 2:36 PM, Ken Gunderson <[EMAIL PROTECTED]> wrote: > On Wed, 6 Feb 2008 14:12:59 -0600 > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > On Feb 6, 2008 1:16 PM, Joerg Schilling > > <[EMAIL PROTECTED]> wrote: > > > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > > > > > Compared to bash, /bin/sh (the Burne Shell) is bug-free. > > > > > > > > I don't think you'll find many users that agree. > > > > > > This is because most bash users don't understand POSIX nor > > > care about bugs. They are not even interested in knowing the > > > reason for a problem. > > > > Exactly! So why not give them a shell that is POSIX and that is full > > featured and provides something that makes them feel much more at > > home. > > > > s/them/Linuxers/g No; s/them/almost any other users that don't use Solaris/ Seriously; FreeBSD, NetBSD, OpenBSD, GNU/Linux, and many others all provide a better /bin/sh... -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 2:35 PM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > Shawn Walker wrote: > > On Feb 6, 2008 2:26 PM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > > > >> Shawn Walker wrote: > >> > >>> On Feb 6, 2008 1:16 PM, Joerg Schilling > >>> <[EMAIL PROTECTED]> wrote: > >>> > >>> > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > >> Compared to bash, /bin/sh (the Burne Shell) is bug-free. > >> > >> > > I don't think you'll find many users that agree. > > > > > This is because most bash users don't understand POSIX nor > care about bugs. They are not even interested in knowing the > reason for a problem. > > > >>> Exactly! So why not give them a shell that is POSIX and that is full > >>> featured and provides something that makes them feel much more at > >>> home. > >>> > >>> > >>> > >> How is that an 'Exactly!'??? > >> > >> If they don't understand what it means to be POSIX? and they don't care > >> if there are bugs, or care why things are the way they are, How will > >> they notice that you've given them these things they don't care or know > >> enough to recognize? > >> > > > > They do care and they do recognize bugs and problems with Solaris /bin/sh. > > > > GNU/Linux users don't notice these issues with bash is what Joerg was > > talking about. > > > > > ANd giving them ksh (or even dash I imagine) on Solaris isn't going to > be that noticeable then, or any better. Theonly thing they'll > appreciate is giving them bash complete with it's bugs. A working backspace key isn't going to be noticed? Their programs suddenly working without requiring the shell scripts for them to be changed isn't noticeable? Working locale support won't be noticed? Forgive me, but I think you don't realise just how broken /bin/sh is. > >> How will it make them more at home? > >> > > > > A modern shell, such as ksh93, has functionality and locale support > > that is near equivalent or superior to bash. > > > > > But if they don't care, why would they notice? They do care and do notice. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Wed, 6 Feb 2008 14:12:59 -0600 "Shawn Walker" <[EMAIL PROTECTED]> wrote: > On Feb 6, 2008 1:16 PM, Joerg Schilling > <[EMAIL PROTECTED]> wrote: > > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > > > Compared to bash, /bin/sh (the Burne Shell) is bug-free. > > > > > > I don't think you'll find many users that agree. > > > > This is because most bash users don't understand POSIX nor > > care about bugs. They are not even interested in knowing the > > reason for a problem. > > Exactly! So why not give them a shell that is POSIX and that is full > featured and provides something that makes them feel much more at > home. > s/them/Linuxers/g -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: > On Feb 6, 2008 2:26 PM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > >> Shawn Walker wrote: >> >>> On Feb 6, 2008 1:16 PM, Joerg Schilling >>> <[EMAIL PROTECTED]> wrote: >>> >>> "Shawn Walker" <[EMAIL PROTECTED]> wrote: >> Compared to bash, /bin/sh (the Burne Shell) is bug-free. >> >> > I don't think you'll find many users that agree. > > This is because most bash users don't understand POSIX nor care about bugs. They are not even interested in knowing the reason for a problem. >>> Exactly! So why not give them a shell that is POSIX and that is full >>> featured and provides something that makes them feel much more at >>> home. >>> >>> >>> >> How is that an 'Exactly!'??? >> >> If they don't understand what it means to be POSIX? and they don't care >> if there are bugs, or care why things are the way they are, How will >> they notice that you've given them these things they don't care or know >> enough to recognize? >> > > They do care and they do recognize bugs and problems with Solaris /bin/sh. > > GNU/Linux users don't notice these issues with bash is what Joerg was > talking about. > > ANd giving them ksh (or even dash I imagine) on Solaris isn't going to be that noticeable then, or any better. Theonly thing they'll appreciate is giving them bash complete with it's bugs. >> How will it make them more at home? >> > > A modern shell, such as ksh93, has functionality and locale support > that is near equivalent or superior to bash. > > But if they don't care, why would they notice? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Software Change was Re: [osol-announce] No update on SXCE Build 79
Alan Coopersmith wrote: > Kyle McDonald wrote: > >>a) Xscreensaver. The dependency on GTK might be solved similiar to >> DBUS and HAL with packaging. It's my suggestion though that if the >> dependencies for XscreenSaver were considered harder, then a better >> solution might have been found for integrating the Accessibility >> technology into it. For instance it could have been coded to dynamically >> load (and call into) the accessibility libs only if they were present. >> >> This would have allowed it to be installed and function with out >> any GNOME packages, and the the dependencies they bring, and yet would >> have enable that functionality if they were present. >> > > The missing link here is deciding it's worthwhile to do that work. > Yes. I expected that there will be times when the work is considered too large a job for the immediate timeframe. It was just the best example I could come up with, to show what I was thinking of, and explain where I think the *process* should change to at least stop, consider options like this and make a consious decision whether to require the work be done now, postpone it for the future, or skip it forever. Maybe this happens now. But I get the (possibly wrong) feeling that some of these things aren't really even thought about. > When xscreensaver was added to Solaris during one of the Solaris 9 > update releases it was explicitly to provide a screensaver for the > GNOME 2.0 desktop.Making it depend on GTK+ was a goal of that > work - making it installable without any GNOME libraries was not, > and is still not a goal today for those at Sun paid to do this work. > > These resource constraints are always going to exist. Even if a community memeber wnated to make these changes, it seems to me that they'll always be playing catchup, always be after the fact, because I don't see any company allowing the community to say "Wait, don't integrate that until we have a chance to do all the other work that we think needs to be done, that you're not willing to pay for." So what can we do to stop situations like these from even being introduced into solaris to begin with? -Kyle > If a community member felt that this was so worthwhile to put in the > work themselves, the code is open, and we take contributions, but Sun > has no reason to spend its resources doing it ourselves. > > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 2:26 PM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > Shawn Walker wrote: > > On Feb 6, 2008 1:16 PM, Joerg Schilling > > <[EMAIL PROTECTED]> wrote: > > > >> "Shawn Walker" <[EMAIL PROTECTED]> wrote: > >> > >> > Compared to bash, /bin/sh (the Burne Shell) is bug-free. > > >>> I don't think you'll find many users that agree. > >>> > >> This is because most bash users don't understand POSIX nor > >> care about bugs. They are not even interested in knowing the > >> reason for a problem. > >> > > > > Exactly! So why not give them a shell that is POSIX and that is full > > featured and provides something that makes them feel much more at > > home. > > > > > How is that an 'Exactly!'??? > > If they don't understand what it means to be POSIX? and they don't care > if there are bugs, or care why things are the way they are, How will > they notice that you've given them these things they don't care or know > enough to recognize? They do care and they do recognize bugs and problems with Solaris /bin/sh. GNU/Linux users don't notice these issues with bash is what Joerg was talking about. > How will it make them more at home? A modern shell, such as ksh93, has functionality and locale support that is near equivalent or superior to bash. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: > On Feb 6, 2008 1:16 PM, Joerg Schilling > <[EMAIL PROTECTED]> wrote: > >> "Shawn Walker" <[EMAIL PROTECTED]> wrote: >> >> Compared to bash, /bin/sh (the Burne Shell) is bug-free. >>> I don't think you'll find many users that agree. >>> >> This is because most bash users don't understand POSIX nor >> care about bugs. They are not even interested in knowing the >> reason for a problem. >> > > Exactly! So why not give them a shell that is POSIX and that is full > featured and provides something that makes them feel much more at > home. > > How is that an 'Exactly!'??? If they don't understand what it means to be POSIX? and they don't care if there are bugs, or care why things are the way they are, How will they notice that you've given them these things they don't care or know enough to recognize? How will it make them more at home? -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Software Change was Re: [osol-announce] No update on SXCE Build 79
Ken Gunderson wrote: > On Wed, 06 Feb 2008 10:46:54 -0800 > Alan Coopersmith <[EMAIL PROTECTED]> wrote: >> Kyle McDonald wrote: >> The missing link here is deciding it's worthwhile to do that work. >> When xscreensaver was added to Solaris during one of the Solaris 9 >> update releases it was explicitly to provide a screensaver for the >> GNOME 2.0 desktop.Making it depend on GTK+ was a goal of that >> work - making it installable without any GNOME libraries was not, >> and is still not a goal today for those at Sun paid to do this work. > > "Making it depend on GTK+ was a goal of that work" > > Wow!! That's some extrordinarily bizarre goal setting there... > Assumption that anyone running X will _also_necessarily want to be > dependent on Gnome. Now to say that you're too lazy to separate the > two is one thing, but to pass off as a "featured goal" is quite > another, imho. I can imagine how the KDE4 integration team is feeling > about that (just as one example from w/in Sun itself). Only if you make the assumption that anyone running X but not running GNOME will want to run the xscreensaver we built for GNOME integration - I certainly don't assume that, and you can easily run X without it. Sun's goal at the time was to deliver a GNOME desktop that met the requirements of the US Government Section 508 regulations on Accessibility. The interfaces available to meet that were GTK+ or Java Swing, so GTK+ was chosen to reduce the change to porting the unlock dialog to a new toolkit instead of porting to an entire new language & runtime environment. Since Sun was only shipping CDE & GNOME, and CDE already had a screen lock, and Solaris already had xlock for other desktops, xscreensaver was not viewed as a generic X desktop feature, but part of the GNOME desktop. There's nothing stopping anyone who wants to build their own desktop, such as KDE, from building their own xscreensaver using another toolkit, or xlockmore or another screen lock, or even using the Solaris provided xlock. Of course, if they want xscreensaver to not use GTK+ at all, they'll also be forking from upstream, since jwz (the upstream maintainer) has chosen GTK+ as the toolkit for the preferences interface, while he does not use it for the unlock dialog as we do. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 1:16 PM, Joerg Schilling <[EMAIL PROTECTED]> wrote: > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > Compared to bash, /bin/sh (the Burne Shell) is bug-free. > > > > I don't think you'll find many users that agree. > > This is because most bash users don't understand POSIX nor > care about bugs. They are not even interested in knowing the > reason for a problem. Exactly! So why not give them a shell that is POSIX and that is full featured and provides something that makes them feel much more at home. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 1:45 PM, <[EMAIL PROTECTED]> wrote: > > > >FYI Ubuntu uses dash as /bin/sh and Suse will use dash in the future. > >ksh93 has been discussed but it needs to be licensed as LGPL or GPL > >before Suse can use ksh93 as /bin/sh. > > > Dash? That's a new one (and a brand of detergent for washing machines) > > Why not gosh? (Which would be the name of the be-all, end-all of shell's: > God's Own Shell) That, would be a truly great name :) Yes, dash is one of the many reasons I would like to see /bin/sh be a POSIX shell. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
On Wed, 06 Feb 2008 20:02:37 +0100 [EMAIL PROTECTED] wrote: > > >"Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > >> Ultimately, /sbin/sh is an unacceptable shell in a modern environme= > >nt > >> for a variety of reasons. > >> > >> It isn't even POSIX compliant, and the base system shell should be. > > > >POSIX does not deal with path names and thus does not require that > >/bin/sh is POSIX compliant. > > > >Backwards compatibility requiers that /bin/sh remains the Bourne Shel= > >l. > > But we're free to change root's shell to /bin/ksh93 fwiw; # uname -s OpenBSD # crontab -l|grep -i shell SHELL=/bin/sh # grep ^root /etc/passwd |cut -d : -f 1,7 root:/bin/ksh -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Software Change was Re: [osol-announce] No update on SXCE Build 79
On Wed, 06 Feb 2008 10:46:54 -0800 Alan Coopersmith <[EMAIL PROTECTED]> wrote: > Kyle McDonald wrote: > >a) Xscreensaver. The dependency on GTK might be solved similiar to > > DBUS and HAL with packaging. It's my suggestion though that if the > > dependencies for XscreenSaver were considered harder, then a better > > solution might have been found for integrating the Accessibility > > technology into it. For instance it could have been coded to dynamically > > load (and call into) the accessibility libs only if they were present. > > > > This would have allowed it to be installed and function with out > > any GNOME packages, and the the dependencies they bring, and yet would > > have enable that functionality if they were present. > > The missing link here is deciding it's worthwhile to do that work. > When xscreensaver was added to Solaris during one of the Solaris 9 > update releases it was explicitly to provide a screensaver for the > GNOME 2.0 desktop.Making it depend on GTK+ was a goal of that > work - making it installable without any GNOME libraries was not, > and is still not a goal today for those at Sun paid to do this work. "Making it depend on GTK+ was a goal of that work" Wow!! That's some extrordinarily bizarre goal setting there... Assumption that anyone running X will _also_necessarily want to be dependent on Gnome. Now to say that you're too lazy to separate the two is one thing, but to pass off as a "featured goal" is quite another, imho. I can imagine how the KDE4 integration team is feeling about that (just as one example from w/in Sun itself). -- Best regards, Ken Gunderson Q: Because it reverses the logical flow of conversation. A: Why is putting a reply at the top of the message frowned upon? ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
>FYI Ubuntu uses dash as /bin/sh and Suse will use dash in the future. >ksh93 has been discussed but it needs to be licensed as LGPL or GPL >before Suse can use ksh93 as /bin/sh. Dash? That's a new one (and a brand of detergent for washing machines) Why not gosh? (Which would be the name of the be-all, end-all of shell's: God's Own Shell) Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
"Shawn Walker" <[EMAIL PROTECTED]> wrote: > > Compared to bash, /bin/sh (the Burne Shell) is bug-free. > > I don't think you'll find many users that agree. This is because most bash users don't understand POSIX nor care about bugs. They are not even interested in knowing the reason for a problem. bash e.g. ignores "-e" under some conditions. This results in nested make(1) calls that loop over lists not to abort on make errors. Check Google for bugreports and you will find that Linux people claim this is not a bash bug. If you like to discuss your claim, we first need to select only those people who know what a shell bug is. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On 2/6/08, Bruno Jargot <[EMAIL PROTECTED]> wrote: > On 2/6/08, Shawn Walker <[EMAIL PROTECTED]> wrote: > > On Feb 6, 2008 11:23 AM, Joerg Schilling > > <[EMAIL PROTECTED]> wrote: > > > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > > > > On Feb 6, 2008 11:08 AM, Joerg Schilling > > > > <[EMAIL PROTECTED]> wrote: > > > > > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > Ultimately, /sbin/sh is an unacceptable shell in a modern > > > > > > environment > > > > > > for a variety of reasons. > > > > > > > > > > > > It isn't even POSIX compliant, and the base system shell should be. > > > > > > > > > > POSIX does not deal with path names and thus does not require that > > > > > /bin/sh is POSIX compliant. > > > > > > > > What do path names have to do with the shell command language? > > > > > > Please try to understand how POSIX works > > > > > > POSIX requires a POSIX compliant shell to be available if ou type "sh" > > > after you typed: "PATH=`getconf PATH`" > > > > > > POSIX does _not_ deal with PATH names and thus does not say anything about > > > /bin/sh. > > > > I know that. You were assuming that I cared that POSIX said whether > > /bin/sh should be a POSIX shell. > > > > I don't. > > > > All I care about is that the default shell used by root, etc. is: > > > > 1) *NOT* POSIX compliant > > > > 2) Buggy > > > > 3) Provides a poor user experience > > > > 4) Lacks proper internationalization support > > > > 5) Reflects poorly on Solaris > > > > 6) Hasn't been actively maintained > > > > 7) Continues to cause issues for users and developers when dealing > > with multiple systems > > > > ...I could think of others, but the point is that there are better > > options available. > > +1 > > I think we should congratulate the person who had the guts to change > /sbin/sh to ksh93 in Indiana. There is no point to turn Opensolaris > into the last stronghold of the Bourne shell while everyone else moved > to a POSIX shell +1 Josh ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On 2/6/08, Shawn Walker <[EMAIL PROTECTED]> wrote: > On Feb 6, 2008 12:30 PM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > > Shawn Walker wrote: > > > On Feb 6, 2008 11:59 AM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > > > > > >> Joerg Schilling wrote: > > >> > > >>> "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > >>> > > >>> > > 1) *NOT* POSIX compliant > > > > > > >>> If you have problems with that, you may modify /etc/passwd > > >>> > > >>> > > >> Since it seems that one group cares more about what they end up with > > >> when they login as, or su to root, and the other group seems to care > > >> more about scripts that use #!/bin/sh running correctly, then maybe, > > >> just maybe (dare I say it?) the solution is to just make the default > > >> passwd entry for root specify /bin/ksh (or ksh93 if they aren't the > > >> same?) > > >> > > >> That seems to cover most if not all of the concerns I've heard voiced, > > >> unless I missed something. > > >> > > >> Personally, when I work as 'root' I automatically get the shell from my > > >> own account, not root's so this change doesn't affect me much. > > >> > > > > > > The issue doesn't have to do with which default shell the user has; > > > > > > It has to do with what shell is used when a script is executed that > > > has "#!/bin/sh" at the top. > > > > > > For system administrators that have to maintain software for a > > > non-heterogeneous environment, it is one more thing they have to deal > > > with. > > > > > > > > I think you mean 'non-homogeneous'. ;) Otherwise you'd have no problems > > because you'd have no different platforms. > > Yeah, sorry. > > > If linux is one of your platforms though, then you still have problems, > > since /bin/sh is bash on there, and not ksh93, and you'll still have > > feature, and behaviour differences to work around. > > Many Linux distributions are starting to shift towards making /bin/sh > a POSIX one; Debian I believe was mentioned in passing about this > particular topic. Ubuntu uses dash and Suse will use dash in the future > > Maintaining something broken in the name of continuing broken-ness > doesn't seem like a good idea to me :) +1 Josh ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On 2/6/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > >1) *NOT* POSIX compliant > >7) Continues to cause issues for users and developers when dealing > >with multiple systems > > 7, unfortunately, is not as it requires replacing /bin/sh with /bin/bash > and that, I think, it something few would be willing to do. FYI Ubuntu uses dash as /bin/sh and Suse will use dash in the future. ksh93 has been discussed but it needs to be licensed as LGPL or GPL before Suse can use ksh93 as /bin/sh. Josh ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 1:10 PM, <[EMAIL PROTECTED]> wrote: > 7, unfortunately, is not as it requires replacing /bin/sh with /bin/bash > and that, I think, it something few would be willing to do. I don't see why 7 isn't an option, even if it does cause *some* degree of break in compatibility. I think the problems caused by #!/bin/sh *not* being a decent shell are greater than what little value there is in keeping it. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
>I think you mean 'non-homogeneous'. ;) Otherwise you'd have no problems >because you'd have no different platforms. > >If linux is one of your platforms though, then you still have problems, >since /bin/sh is bash on there, and not ksh93, and you'll still have >feature, and behaviour differences to work around. Yeah, I don't think this fixes anything there except if people know how to program to the POSIX shell which few people do. So if you really write substantial scripts and don't know how to do that in the least Common Denominator, then perhaps shell programming is not for you (so use something else like python or perl) Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 1:05 PM, <[EMAIL PROTECTED]> wrote: > > >> POSIX does not deal with path names and thus does not require that > >> /bin/sh is POSIX compliant. > > > >What do path names have to do with the shell command language? > > I think Joerg means "the base system shell need not be /bin/sh". > > (I.e., the pathname to the base system shell is not defined and neither > is the path to the standard shell in POSIX) > > >http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html > > > >> Backwards compatibility requiers that /bin/sh remains the Bourne Shell. > > > >I don't agree. > > We have shown that sh and ksh93 are not compatible; in order to avoid > ANY breakage you would need to not change it. I think there is no > denying that fact. > > (Or you need to proof that there are no /bin/sh scripts in use on Solaris > which execute differently under ksh/ksh93) ...ksh93 can be modified to provide backwards compatibility where possible. Which is why I said I don't agree. While it may be that 100% backwards compatibility cannot be maintained (it is difficult to tell until all of the cases are dealt with), 99% may be good enough. In the end, it may be worth not keeping backwards compatibility with such a broken shell. But that isn't for me to decide, even though I hope it happens. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
>Since it seems that one group cares more about what they end up with >when they login as, or su to root, and the other group seems to care >more about scripts that use #!/bin/sh running correctly, then maybe, >just maybe (dare I say it?) the solution is to just make the default >passwd entry for root specify /bin/ksh (or ksh93 if they aren't the same?) > >That seems to cover most if not all of the concerns I've heard voiced, >unless I missed something. > >Personally, when I work as 'root' I automatically get the shell from my >own account, not root's so this change doesn't affect me much. Same here. Perhaps change "su" to behave that way, optionally, for admins? Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
>1) *NOT* POSIX compliant > >2) Buggy > >3) Provides a poor user experience > >4) Lacks proper internationalization support > >5) Reflects poorly on Solaris > >6) Hasn't been actively maintained > >7) Continues to cause issues for users and developers when dealing >with multiple systems 1-6 are easily solved with changing root's default shell. 7, unfortunately, is not as it requires replacing /bin/sh with /bin/bash and that, I think, it something few would be willing to do. Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
>> POSIX does not deal with path names and thus does not require that >> /bin/sh is POSIX compliant. > >What do path names have to do with the shell command language? I think Joerg means "the base system shell need not be /bin/sh". (I.e., the pathname to the base system shell is not defined and neither is the path to the standard shell in POSIX) >http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html > >> Backwards compatibility requiers that /bin/sh remains the Bourne Shell. > >I don't agree. We have shown that sh and ksh93 are not compatible; in order to avoid ANY breakage you would need to not change it. I think there is no denying that fact. (Or you need to proof that there are no /bin/sh scripts in use on Solaris which execute differently under ksh/ksh93) Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 12:49 PM, Joerg Schilling <[EMAIL PROTECTED]> wrote: > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > Sorry, but unless you are able to explain problems, I ned to asume that > > > you > > > don't know what you are talking about. > > > > > > Why should sh have problems with "certain terminals"? > > > > > > What do you understand by "locale support". > > > > > > Writing unspecified claims does not allow to have a fact based discussion. > > > > Joerg, look at the bug database. It is pointless for me to restate > > bugs that have already been recorded. > > If you cannot name bug id's we need to stop here and conclude there are no > problems with sh. Didn't you reprimand someone the other day for not reading the SchilliX readme? The tools are available for you to find the bugs if you want to see them. It took me all of a few moments to put together these searches: http://bugs.opensolaris.org/bugdatabase/search.do?process=1&type=bug&sortBy=relevance&bugStatus=1-dispatched&perPage=10&bugId=&keyword=&textSearch=&category=shell&subcategory=bourne&since= http://bugs.opensolaris.org/bugdatabase/search.do?process=1&type=bug&sortBy=relevance&bugStatus=3-accepted&perPage=10&bugId=&keyword=&textSearch=&category=shell&subcategory=bourne&since= ... I could go on, but what would be the point? There are at least 60-70 bugs that I've found just looking through those pages. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
>"Shawn Walker" <[EMAIL PROTECTED]> wrote: > >> Ultimately, /sbin/sh is an unacceptable shell in a modern environme= >nt >> for a variety of reasons. >> >> It isn't even POSIX compliant, and the base system shell should be. > >POSIX does not deal with path names and thus does not require that >/bin/sh is POSIX compliant. > >Backwards compatibility requiers that /bin/sh remains the Bourne Shel= >l. But we're free to change root's shell to /bin/ksh93 Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 12:47 PM, Joerg Schilling <[EMAIL PROTECTED]> wrote: > Kyle McDonald <[EMAIL PROTECTED]> wrote: > > > If linux is one of your platforms though, then you still have problems, > > since /bin/sh is bash on there, and not ksh93, and you'll still have > > feature, and behaviour differences to work around. > > And on Linux, you have _real_ problems bacause of the fact that /bin/sh is > bash > and because bash illegally does jobcontrol with /bin/sh -c "command", causing > really annoying bugs with nested make(1) calls unless the make source contains > a workaround for the bug. There are many other problems in bash > > Compared to bash, /bin/sh (the Burne Shell) is bug-free. I don't think you'll find many users that agree. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 12:30 PM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > Shawn Walker wrote: > > On Feb 6, 2008 11:59 AM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > > > >> Joerg Schilling wrote: > >> > >>> "Shawn Walker" <[EMAIL PROTECTED]> wrote: > >>> > >>> > 1) *NOT* POSIX compliant > > > >>> If you have problems with that, you may modify /etc/passwd > >>> > >>> > >> Since it seems that one group cares more about what they end up with > >> when they login as, or su to root, and the other group seems to care > >> more about scripts that use #!/bin/sh running correctly, then maybe, > >> just maybe (dare I say it?) the solution is to just make the default > >> passwd entry for root specify /bin/ksh (or ksh93 if they aren't the same?) > >> > >> That seems to cover most if not all of the concerns I've heard voiced, > >> unless I missed something. > >> > >> Personally, when I work as 'root' I automatically get the shell from my > >> own account, not root's so this change doesn't affect me much. > >> > > > > The issue doesn't have to do with which default shell the user has; > > > > It has to do with what shell is used when a script is executed that > > has "#!/bin/sh" at the top. > > > > For system administrators that have to maintain software for a > > non-heterogeneous environment, it is one more thing they have to deal > > with. > > > > > I think you mean 'non-homogeneous'. ;) Otherwise you'd have no problems > because you'd have no different platforms. Yeah, sorry. > If linux is one of your platforms though, then you still have problems, > since /bin/sh is bash on there, and not ksh93, and you'll still have > feature, and behaviour differences to work around. Many Linux distributions are starting to shift towards making /bin/sh a POSIX one; Debian I believe was mentioned in passing about this particular topic. Maintaining something broken in the name of continuing broken-ness doesn't seem like a good idea to me :) -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
"Shawn Walker" <[EMAIL PROTECTED]> wrote: > > Sorry, but unless you are able to explain problems, I ned to asume that you > > don't know what you are talking about. > > > > Why should sh have problems with "certain terminals"? > > > > What do you understand by "locale support". > > > > Writing unspecified claims does not allow to have a fact based discussion. > > Joerg, look at the bug database. It is pointless for me to restate > bugs that have already been recorded. If you cannot name bug id's we need to stop here and conclude there are no problems with sh. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
Kyle McDonald <[EMAIL PROTECTED]> wrote: > If linux is one of your platforms though, then you still have problems, > since /bin/sh is bash on there, and not ksh93, and you'll still have > feature, and behaviour differences to work around. And on Linux, you have _real_ problems bacause of the fact that /bin/sh is bash and because bash illegally does jobcontrol with /bin/sh -c "command", causing really annoying bugs with nested make(1) calls unless the make source contains a workaround for the bug. There are many other problems in bash Compared to bash, /bin/sh (the Burne Shell) is bug-free. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Software Change was Re: [osol-announce] No update on SXCE Build 79
Kyle McDonald wrote: >a) Xscreensaver. The dependency on GTK might be solved similiar to > DBUS and HAL with packaging. It's my suggestion though that if the > dependencies for XscreenSaver were considered harder, then a better > solution might have been found for integrating the Accessibility > technology into it. For instance it could have been coded to dynamically > load (and call into) the accessibility libs only if they were present. > > This would have allowed it to be installed and function with out > any GNOME packages, and the the dependencies they bring, and yet would > have enable that functionality if they were present. The missing link here is deciding it's worthwhile to do that work. When xscreensaver was added to Solaris during one of the Solaris 9 update releases it was explicitly to provide a screensaver for the GNOME 2.0 desktop.Making it depend on GTK+ was a goal of that work - making it installable without any GNOME libraries was not, and is still not a goal today for those at Sun paid to do this work. If a community member felt that this was so worthwhile to put in the work themselves, the code is open, and we take contributions, but Sun has no reason to spend its resources doing it ourselves. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: > On Feb 6, 2008 11:59 AM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > >> Joerg Schilling wrote: >> >>> "Shawn Walker" <[EMAIL PROTECTED]> wrote: >>> >>> 1) *NOT* POSIX compliant >>> If you have problems with that, you may modify /etc/passwd >>> >>> >> Since it seems that one group cares more about what they end up with >> when they login as, or su to root, and the other group seems to care >> more about scripts that use #!/bin/sh running correctly, then maybe, >> just maybe (dare I say it?) the solution is to just make the default >> passwd entry for root specify /bin/ksh (or ksh93 if they aren't the same?) >> >> That seems to cover most if not all of the concerns I've heard voiced, >> unless I missed something. >> >> Personally, when I work as 'root' I automatically get the shell from my >> own account, not root's so this change doesn't affect me much. >> > > The issue doesn't have to do with which default shell the user has; > > It has to do with what shell is used when a script is executed that > has "#!/bin/sh" at the top. > > For system administrators that have to maintain software for a > non-heterogeneous environment, it is one more thing they have to deal > with. > > I think you mean 'non-homogeneous'. ;) Otherwise you'd have no problems because you'd have no different platforms. If linux is one of your platforms though, then you still have problems, since /bin/sh is bash on there, and not ksh93, and you'll still have feature, and behaviour differences to work around. -Kyle > Ensuring that #!/bin/sh was a POSIX-compliant shell on the majority of > UNIX and UNIX-like environments would go a long way towards easing > administrative and development pain for many individuals. > > ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 12:16 PM, Joerg Schilling <[EMAIL PROTECTED]> wrote: > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > > 2) Buggy > > > > > > What bugs? > > > > Take your pick from bugs.opensolaris.org. > > > > Notably, there are problems with: > > > > 1) certain terminals > > > > 2) locale support, etc. > > Sorry, but unless you are able to explain problems, I ned to asume that you > don't know what you are talking about. > > Why should sh have problems with "certain terminals"? > > What do you understand by "locale support". > > Writing unspecified claims does not allow to have a fact based discussion. Joerg, look at the bug database. It is pointless for me to restate bugs that have already been recorded. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Software Change was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: > On Feb 6, 2008 11:41 AM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > >> Shawn Walker wrote: >> >>> On Feb 6, 2008 10:31 AM, Kyle McDonald <[EMAIL PROTECTED]> wrote: >>> >>> Shawn Walker wrote: > Yes, I am trying to say that packaging is the issue here, not software. > > > > No. Dependencies are the issue. Many dependencies are created when the >>> Dependencies are a result of packaging in most cases, so I don't see >>> how what you are saying is much different than what I am saying. >>> >>> I'm fairly certain we're effectively saying the same thing. >>> >>> >>> >> No you're missing the distinction (it may be fine, but it's important.) >> > > > > No, I'm actually not. > > Development decisions had no relevance (in my mind) to the original > perceived issue in question. > > DBUS and HAL are reasonable dependencies to have, and I don't see any > practical alternatives unless you want to have to maintain multiple > methods of doing the same thing. > > Yes in that example they were reasonable. Should have been in separate package, and all would have been well. I'm trying to make 2 points: 1) The case for the integration of the new removable media volume manager should have identified this problem, and required it to be fixed before integration. In other words the development process for proposing, considering, and integrating changes, should have packaging as a high level consideration. 2) There are many other examples where the solution is not as easy as DBUS and HAL. a) Xscreensaver. The dependency on GTK might be solved similiar to DBUS and HAL with packaging. It's my suggestion though that if the dependencies for XscreenSaver were considered harder, then a better solution might have been found for integrating the Accessibility technology into it. For instance it could have been coded to dynamically load (and call into) the accessibility libs only if they were present. This would have allowed it to be installed and function with out any GNOME packages, and the the dependencies they bring, and yet would have enable that functionality if they were present. b) The perl example I listed in my last email, actually happened in Solaris. I don't remember when (Solaris 8 or 9 maybe.) I didn't need perl on any of my machines, I was willing to live with one version, but was unable to remove either one, because that require removing features I wanted to keep. Why couldn't these other features use the same perl? (limited development resources, I know - but still not a good design.) Both of those examples requre thought and consideration at design and coding time, and no packaging changes are going to fix the dependencies. >> I was trying to add that I believe fixing packaging boundaries, and >> dependencies is a higher priority than new packaging technology. Enough so >> that a coordinated examination and effort (Is there one already?) across all >> of solaris would be a good idea, rather than leaving it to the different >> projects to realize the limits of their current pacakges, and fix them at >> their own pace. >> > > In the original case being discussed, I still think it is packaging > (which I think boundaries falls within) Yes I agree package boundaries falls in the subject of packaging. > that was the issue and not development choices. > > In that case yes. But not all cases. -Kytle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
"Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > 2) Buggy > > > > What bugs? > > Take your pick from bugs.opensolaris.org. > > Notably, there are problems with: > > 1) certain terminals > > 2) locale support, etc. Sorry, but unless you are able to explain problems, I ned to asume that you don't know what you are talking about. Why should sh have problems with "certain terminals"? What do you understand by "locale support". Writing unspecified claims does not allow to have a fact based discussion. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On 2/6/08, Joerg Schilling <[EMAIL PROTECTED]> wrote: > "Bruno Jargot" <[EMAIL PROTECTED]> wrote: > > > > > I think we should congratulate the person who had the guts to change > > > > /sbin/sh to ksh93 in Indiana. There is no point to turn Opensolaris > > > > into the last stronghold of the Bourne shell while everyone else moved > > > > to a POSIX shell > > > > > > This is nothing to congrat as this change introduces a lot of unwanted > > > incompatibilities. > > > > Someone had the guts to stand up against the ultraconservative > > 'backwards compatibility is our religion' [EMAIL PROTECTED] > > Opensolaris cannot afford such Bourne shell extravaganza anymore > > OpenSolaris cannot afford headless changes. I do not think this change is headless Bruno ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
"Bruno Jargot" <[EMAIL PROTECTED]> wrote: > > > I think we should congratulate the person who had the guts to change > > > /sbin/sh to ksh93 in Indiana. There is no point to turn Opensolaris > > > into the last stronghold of the Bourne shell while everyone else moved > > > to a POSIX shell > > > > This is nothing to congrat as this change introduces a lot of unwanted > > incompatibilities. > > Someone had the guts to stand up against the ultraconservative > 'backwards compatibility is our religion' [EMAIL PROTECTED] > Opensolaris cannot afford such Bourne shell extravaganza anymore OpenSolaris cannot afford headless changes. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On 2/6/08, Joerg Schilling <[EMAIL PROTECTED]> wrote: > "Bruno Jargot" <[EMAIL PROTECTED]> wrote: > > > > > I think we should congratulate the person who had the guts to change > > /sbin/sh to ksh93 in Indiana. There is no point to turn Opensolaris > > into the last stronghold of the Bourne shell while everyone else moved > > to a POSIX shell > > This is nothing to congrat as this change introduces a lot of unwanted > incompatibilities. Someone had the guts to stand up against the ultraconservative 'backwards compatibility is our religion' [EMAIL PROTECTED] Opensolaris cannot afford such Bourne shell extravaganza anymore Bruno ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 11:39 AM, Joerg Schilling <[EMAIL PROTECTED]> wrote: > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > POSIX does _not_ deal with PATH names and thus does not say anything about > > > /bin/sh. > > > > I know that. You were assuming that I cared that POSIX said whether > > /bin/sh should be a POSIX shell. > > > > I don't. > > > > All I care about is that the default shell used by root, etc. is: > > > > 1) *NOT* POSIX compliant > > If you have problems with that, you may modify /etc/passwd > > > 2) Buggy > > What bugs? Take your pick from bugs.opensolaris.org. Notably, there are problems with: 1) certain terminals 2) locale support, etc. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 11:59 AM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > Joerg Schilling wrote: > > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > >> 1) *NOT* POSIX compliant > >> > > > > If you have problems with that, you may modify /etc/passwd > > > Since it seems that one group cares more about what they end up with > when they login as, or su to root, and the other group seems to care > more about scripts that use #!/bin/sh running correctly, then maybe, > just maybe (dare I say it?) the solution is to just make the default > passwd entry for root specify /bin/ksh (or ksh93 if they aren't the same?) > > That seems to cover most if not all of the concerns I've heard voiced, > unless I missed something. > > Personally, when I work as 'root' I automatically get the shell from my > own account, not root's so this change doesn't affect me much. The issue doesn't have to do with which default shell the user has; It has to do with what shell is used when a script is executed that has "#!/bin/sh" at the top. For system administrators that have to maintain software for a non-heterogeneous environment, it is one more thing they have to deal with. Ensuring that #!/bin/sh was a POSIX-compliant shell on the majority of UNIX and UNIX-like environments would go a long way towards easing administrative and development pain for many individuals. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 11:59 AM, Joerg Schilling <[EMAIL PROTECTED]> wrote: > "Bruno Jargot" <[EMAIL PROTECTED]> wrote: > > > > > I think we should congratulate the person who had the guts to change > > /sbin/sh to ksh93 in Indiana. There is no point to turn Opensolaris > > into the last stronghold of the Bourne shell while everyone else moved > > to a POSIX shell > > This is nothing to congrat as this change introduces a lot of unwanted > incompatibilities. Unless you can detail all of those specific incompatibilities, your comments will be dismissed as "hand waving." In other words, beyond a few small examples I've seen, I have yet to hear any real details of incompatibility beyond hypothetical situations. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Software Change was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 11:41 AM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > Shawn Walker wrote: > > On Feb 6, 2008 10:31 AM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > > > >> Shawn Walker wrote: > >> > >>> Yes, I am trying to say that packaging is the issue here, not software. > >>> > >>> > >>> > >> No. Dependencies are the issue. Many dependencies are created when the > >> > > > > Dependencies are a result of packaging in most cases, so I don't see > > how what you are saying is much different than what I am saying. > > > > I'm fairly certain we're effectively saying the same thing. > > > > > No you're missing the distinction (it may be fine, but it's important.) No, I'm actually not. Development decisions had no relevance (in my mind) to the original perceived issue in question. DBUS and HAL are reasonable dependencies to have, and I don't see any practical alternatives unless you want to have to maintain multiple methods of doing the same thing. I didn't miss your distinction; I was merely dismissing it as unrelated. > >> Also I think most dependency problems that can be fixed by re-packaging, > >> can be fixed today with the current pacakging tools. It just takes a > >> finer resolution of packges, and likely an explosion in the number of > >> packages. The problems in the packaging, and the problems being solved > >> in the packaging tools I think, are largely ( though maybe not entirely) > >> orthogonal, and unrelated. > >> > > > > Didn't I just say the problem is the packaging? > > > > > I was trying to add that I believe fixing packaging boundaries, and > dependencies is a higher priority than new packaging technology. Enough > so that a coordinated examination and effort (Is there one already?) > across all of solaris would be a good idea, rather than leaving it to > the different projects to realize the limits of their current pacakges, > and fix them at their own pace. In the original case being discussed, I still think it is packaging (which I think boundaries falls within) that was the issue and not development choices. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
On 2/6/08, Joerg Schilling <[EMAIL PROTECTED]> wrote: > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > Ultimately, /sbin/sh is an unacceptable shell in a modern environment > > for a variety of reasons. > > > > It isn't even POSIX compliant, and the base system shell should be. > > POSIX does not deal with path names and thus does not require that > /bin/sh is POSIX compliant. Every reasonable Unix platform (except S(ch)illyX maybe) has started to move it's implementation of /bin/sh towards the POSIX standard. How long can Opensolaris ignore this? Bruno ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
Joerg Schilling wrote: > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > >> 1) *NOT* POSIX compliant >> > > If you have problems with that, you may modify /etc/passwd > Since it seems that one group cares more about what they end up with when they login as, or su to root, and the other group seems to care more about scripts that use #!/bin/sh running correctly, then maybe, just maybe (dare I say it?) the solution is to just make the default passwd entry for root specify /bin/ksh (or ksh93 if they aren't the same?) That seems to cover most if not all of the concerns I've heard voiced, unless I missed something. Personally, when I work as 'root' I automatically get the shell from my own account, not root's so this change doesn't affect me much. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
"Bruno Jargot" <[EMAIL PROTECTED]> wrote: > > I think we should congratulate the person who had the guts to change > /sbin/sh to ksh93 in Indiana. There is no point to turn Opensolaris > into the last stronghold of the Bourne shell while everyone else moved > to a POSIX shell This is nothing to congrat as this change introduces a lot of unwanted incompatibilities. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On 2/6/08, Shawn Walker <[EMAIL PROTECTED]> wrote: > On Feb 6, 2008 11:23 AM, Joerg Schilling > <[EMAIL PROTECTED]> wrote: > > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > > On Feb 6, 2008 11:08 AM, Joerg Schilling > > > <[EMAIL PROTECTED]> wrote: > > > > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > > > > > > Ultimately, /sbin/sh is an unacceptable shell in a modern environment > > > > > for a variety of reasons. > > > > > > > > > > It isn't even POSIX compliant, and the base system shell should be. > > > > > > > > POSIX does not deal with path names and thus does not require that > > > > /bin/sh is POSIX compliant. > > > > > > What do path names have to do with the shell command language? > > > > Please try to understand how POSIX works > > > > POSIX requires a POSIX compliant shell to be available if ou type "sh" > > after you typed: "PATH=`getconf PATH`" > > > > POSIX does _not_ deal with PATH names and thus does not say anything about > > /bin/sh. > > I know that. You were assuming that I cared that POSIX said whether > /bin/sh should be a POSIX shell. > > I don't. > > All I care about is that the default shell used by root, etc. is: > > 1) *NOT* POSIX compliant > > 2) Buggy > > 3) Provides a poor user experience > > 4) Lacks proper internationalization support > > 5) Reflects poorly on Solaris > > 6) Hasn't been actively maintained > > 7) Continues to cause issues for users and developers when dealing > with multiple systems > > ...I could think of others, but the point is that there are better > options available. +1 I think we should congratulate the person who had the guts to change /sbin/sh to ksh93 in Indiana. There is no point to turn Opensolaris into the last stronghold of the Bourne shell while everyone else moved to a POSIX shell Bruno ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] A strange crash issue
Hello, Recently, I find a crash issue with my Sparc SunFire V215 server. The OS is nv76. I doubt that it is probably related to writing debug message to the log file : /var/adm/messages, because crash seems happen more often if my driver allows more debug messages to be written into the log file. But I am not very sure yet. All of these fatal error occured in: "PCIe root complex" and running "px_err_panic ". Below is my analysis using mdb. There might be one or more different threads running when panic happens, but one thread writing messages as below always appears in all crash dump, see the result of " 30001418080::findstack -v " below. Is it truly a log message writing bug of the OS? Tom ::msgbuf panic[cpu0]/thread=3000201ec20: Fatal error has occured in: PCIe root complex. 02a10045fd50 px:px_err_panic+164 (11, 1, 13a0400, 2a10045fe00, 2a10045fe01, 0) %l0-3: 0001 0034 018f6400 060010817000 %l4-7: 000ffc00 0183d800 02a10045fe60 px:px_err_dmc_pec_intr+cc (30b5cb0, 0, 30b5d78, 1, 3000 03c6688, 30b5c40) %l0-3: 009882001a02 4000 0003 %l4-7: 004b0918 0011 02a10045ff50 unix:current_thread+1b8 (fa00, 0, 400, 0, 39f1600, fa60 ea00) %l0-3: 010074cc 02a100c952e1 000e 70008440 %l4-7: 001a 0068 03000201ec20 02a100c95b90 syncing file systems... 3 3 done dumping to /dev/dsk/c1t0d0s1, offset 318898176, content: kernel > > ::cpuinfo -v ID ADDRFLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD PROC 0 1838610 1b00 59 nono t-03000201ec20 Xsun | RUNNING <--+ READY EXISTS ENABLE ID ADDRFLG NRUN BSPL PRI RNRN KRNRN SWITCH THREAD PROC 1 180c000 1d50 0 yesno t-90 30001418080 syslogd || RUNNING <--++--> PRI THREAD PROC QUIESCED99 2a100247ca0 sched EXISTS59 3000201e5a0 java ENABLE59 300020e6080 java 59 3000201e260 java 59 3000145b4e0 java A thread writing messages always can be seen in all these crash dumps. c> 30001418080::findstack -v stack pointer for thread 30001418080: 2a10046dca1 [ 02a10046dca1 panic_idle+0x1c() ] 02a10046dd51 ktl0+0x48(, 7f904a00070, 0, 0, 7f9, 30001418080) 02a10046dea1 bcopy_more+0x454(3, 16ec, 1400, 0, , 0) 02a10046dff1 pfb_setup_cmap32+0x74(600108d4000, 0, 14ec, 0, 600108d4aec, 600108d48ec) 02a10046e0c1 pfb_vis_consdisplay+0x138(600108d4000, 580, 1400, 600108d5740 , 1800, 1400) 02a10046e1b1 tem_display_layered+0x20(600109a2f70, 2a10046eb30, 60010803e38, 0, 7c00, 5400) 02a10046e271 tem_pix_cls_range+0xf0(600109a2f70, 0, 1, 360, a0, 50) 02a10046e361 tem_pix_cls+0x3c(0, 50, 21, 0, 60010803e38, 0) 02a10046e431 tem_scroll+0xe0(600109a2f70, 33d4b50, 21, 0, 0, 60010803e38) 02a10046e501 tem_lf+0x50(600109a2f70, 60010803e38, 0, 0, 21, 33d4ac0) 02a10046e5c1 tem_terminal_emulate+0x40(600109a2f70, 6001160a193, 60010803e38, 33d4ac0, 0, 7bb7d15c) 02a10046e671 tem_write+0x30(600109a2f70, 6001160a170, 24, 60010803e38, 1, 600109a2f88) 02a10046e721 wcstart+0xfc(600109c4620, 600122abcc0, 38, 0, 18bc400, 600122abcc0) 02a10046e7d1 wcuwput+0x370(600109c4620, 600122abcc0, 1388, 1388, 2a10046f130, 2a10046a000) 02a10046e881 putnext+0x208(600109c1c28, 600109c4620, 600122abcc0, 0, 1815800, 0) 02a10046e931 ldtermwmsg+0x130(60010ab1068, 600122abcc0, 1388, 0, 0, 2a10046a000) 02a10046e9f1 putnext+0x208(60010ab1160, 60010ab1068, 6001110f040, 0, 1815800, 0) 02a10046eaa1 qdrain_syncq+0x6c(60010ab0e40, 60010ab0dd8, 7005fe90, fffe, 60010ab0ed0, 61) 02a10046eb51 drain_syncq+0x2fc(60010ab0ed0, 11, 11, fffe, 0, fc00) 02a10046ec01 strput+0x1a0(600109c7878, 0, 2a10046fa98, 2a10046f6c0, 0, 0) 02a10046ee01 strwrite_common+0x1f0(600109c2840, 2a10046fa98, 1, 1, 600109c78f8, 600109c7878) 02a10046eed1 iwscnwrite+0x18(e, 2a10046fa98, 60010802458, e, e, 60010a91938) 02a10046ef81 fop_write+0x48(60010b4c300, 2a10046fa98, 0, 60
Re: [osol-discuss] Software Change was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: > On Feb 6, 2008 10:31 AM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > >> Shawn Walker wrote: >> >>> Yes, I am trying to say that packaging is the issue here, not software. >>> >>> >>> >> No. Dependencies are the issue. Many dependencies are created when the >> > > Dependencies are a result of packaging in most cases, so I don't see > how what you are saying is much different than what I am saying. > > I'm fairly certain we're effectively saying the same thing. > > No you're missing the distinction (it may be fine, but it's important.) Hypothetically, Say you're creating some new modular administration tool for all of Solaris, You're thought is to make it web based, and write it in PHP, and use Apache to have it run by default. Serious thought needs to go into whether or not you want basic installs of Solaris to now be *forced* to install Apache and PHP. Alternatives should be considered. Or You're integrating some new feature that you have to have a newer version of Perl than is in Solaris already. Do you just add a second or third version of perl to solaris for you're project? Do you work hard to find a way to get what you need in the existing one? Do you campaign and help to get the other features that use the older versions to move up to your version? Do you Punt on Perl and go back to C? I don't know what the right answer is, but I know I'd hate to end up with 3 version of Perl on my machine. Some base things need to be defined as 'base Solaris' building blocks, and the code for other software allowed to depend on being there. It should be a rare exception that an optional piece of solaris is allowed to require a part that isn't one of these basic blocks. I doubt one group of blocks could be made to work. However, I think a layered set of multiple groups of blocks could be designed so that exceptions would be very rare indeed. But tought and engineering needs to go into this list of goupr of building blocks needs to be available when projects are being planned and coded, not just when they are packaged. > I wasn't suggesting packaging technology was a solution to this. > > Oh. My misunderstanding. >> Also I think most dependency problems that can be fixed by re-packaging, >> can be fixed today with the current pacakging tools. It just takes a >> finer resolution of packges, and likely an explosion in the number of >> packages. The problems in the packaging, and the problems being solved >> in the packaging tools I think, are largely ( though maybe not entirely) >> orthogonal, and unrelated. >> > > Didn't I just say the problem is the packaging? > > I was trying to add that I believe fixing packaging boundaries, and dependencies is a higher priority than new packaging technology. Enough so that a coordinated examination and effort (Is there one already?) across all of solaris would be a good idea, rather than leaving it to the different projects to realize the limits of their current pacakges, and fix them at their own pace. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
"Shawn Walker" <[EMAIL PROTECTED]> wrote: > > POSIX does _not_ deal with PATH names and thus does not say anything about > > /bin/sh. > > I know that. You were assuming that I cared that POSIX said whether > /bin/sh should be a POSIX shell. > > I don't. > > All I care about is that the default shell used by root, etc. is: > > 1) *NOT* POSIX compliant If you have problems with that, you may modify /etc/passwd > 2) Buggy What bugs? Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] /bin/sh was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 11:23 AM, Joerg Schilling <[EMAIL PROTECTED]> wrote: > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > On Feb 6, 2008 11:08 AM, Joerg Schilling > > <[EMAIL PROTECTED]> wrote: > > > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > > > > Ultimately, /sbin/sh is an unacceptable shell in a modern environment > > > > for a variety of reasons. > > > > > > > > It isn't even POSIX compliant, and the base system shell should be. > > > > > > POSIX does not deal with path names and thus does not require that > > > /bin/sh is POSIX compliant. > > > > What do path names have to do with the shell command language? > > Please try to understand how POSIX works > > POSIX requires a POSIX compliant shell to be available if ou type "sh" > after you typed: "PATH=`getconf PATH`" > > POSIX does _not_ deal with PATH names and thus does not say anything about > /bin/sh. I know that. You were assuming that I cared that POSIX said whether /bin/sh should be a POSIX shell. I don't. All I care about is that the default shell used by root, etc. is: 1) *NOT* POSIX compliant 2) Buggy 3) Provides a poor user experience 4) Lacks proper internationalization support 5) Reflects poorly on Solaris 6) Hasn't been actively maintained 7) Continues to cause issues for users and developers when dealing with multiple systems ...I could think of others, but the point is that there are better options available. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
"Shawn Walker" <[EMAIL PROTECTED]> wrote: > On Feb 6, 2008 11:08 AM, Joerg Schilling > <[EMAIL PROTECTED]> wrote: > > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > > Ultimately, /sbin/sh is an unacceptable shell in a modern environment > > > for a variety of reasons. > > > > > > It isn't even POSIX compliant, and the base system shell should be. > > > > POSIX does not deal with path names and thus does not require that > > /bin/sh is POSIX compliant. > > What do path names have to do with the shell command language? Please try to understand how POSIX works POSIX requires a POSIX compliant shell to be available if ou type "sh" after you typed: "PATH=`getconf PATH`" POSIX does _not_ deal with PATH names and thus does not say anything about /bin/sh. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 11:08 AM, Joerg Schilling <[EMAIL PROTECTED]> wrote: > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > Ultimately, /sbin/sh is an unacceptable shell in a modern environment > > for a variety of reasons. > > > > It isn't even POSIX compliant, and the base system shell should be. > > POSIX does not deal with path names and thus does not require that > /bin/sh is POSIX compliant. What do path names have to do with the shell command language? http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html > Backwards compatibility requiers that /bin/sh remains the Bourne Shell. I don't agree. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
"Shawn Walker" <[EMAIL PROTECTED]> wrote: > Ultimately, /sbin/sh is an unacceptable shell in a modern environment > for a variety of reasons. > > It isn't even POSIX compliant, and the base system shell should be. POSIX does not deal with path names and thus does not require that /bin/sh is POSIX compliant. Backwards compatibility requiers that /bin/sh remains the Bourne Shell. Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] on/downloads/current/ restored
On Tue, 5 Feb 2008, Derek Cicero wrote: > It looks like: > > http://dlc.sun.com/osol/on/downloads/current/ Not yet! Take a look at some of the files in downloads/current/. They use a naming convention that includes the date in a format like mmdd - even in the title: "ON (OS/Net) Consolidation - 20080129". Also, take a look at some of the filenames, for example, "on-changelog-20071001.html" which includes the mmdd component. And BTW, the directory "current" does not point to the latest available release. Now the site has been reloaded with a structure that existed earlier (around b62 IIRC). For example, in directory b82 the title is now: "ON (OS/Net) Consolidation - b82" and the files don't use a mmdd component, instead they use the consolidation "b" number. For example: "on-changelog-b82.html". I don't think it matters which filenaming convention you follow, but I would like it to remain *constant* over time. Hmm.. the "bnn" format looks a little cleaner IMHO. > Has been restored, but I am still waiting for official notification that > it's completely in sync. > Regards, Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED] Voice: 972.379.2133 Fax: 972.379.2134 Timezone: US CDT OpenSolaris Governing Board (OGB) Member - Apr 2005 to Mar 2007 http://www.opensolaris.org/os/community/ogb/ogb_2005-2007/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 10:30 AM, Chris Linton-Ford <[EMAIL PROTECTED]> wrote: > > Chris Linton-Ford writes: > > > It might be helpful to consider the shells' dual nature as a) a > > > scripting medium and b) an interactive environment. Surely there is no > > > engineering reason why a shell could not be coded to have only a strict > > > superset of /sbin/sh's commands, thus making scripts compatible. > > > > What's the superset of this? > > > > $ /sbin/sh -c 'foo=a; echo b | read foo; echo $foo' > > a > > $ /usr/bin/ksh93 -c 'foo=a; echo b | read foo; echo $foo' > > b > > > > If ksh93 is incompatible with the existing sh *by design*, then nothing > can be done that will not step on someones toes somewhere. This pretty I don't believe that is the case yet, and quite frankly, hanging to dear life to such a shell that hasn't been updated in years seems silly at best. Quite frankly, I'm tired of hearing people complain about /sbin/sh. People either need to: 1) Propose and to the work necessary to get bsh integrated as /sbin/sh 2) Fix whatever deficiencies they perceive are there The main issue is that even if you fix the few issues that Joerg has fixed, that doesn't solve most of the problems with /sbin/sh. Ultimately, /sbin/sh is an unacceptable shell in a modern environment for a variety of reasons. It isn't even POSIX compliant, and the base system shell should be. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Software Change was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 10:31 AM, Kyle McDonald <[EMAIL PROTECTED]> wrote: > Shawn Walker wrote: > > Yes, I am trying to say that packaging is the issue here, not software. > > > > > No. Dependencies are the issue. Many dependencies are created when the Dependencies are a result of packaging in most cases, so I don't see how what you are saying is much different than what I am saying. I'm fairly certain we're effectively saying the same thing. > I'm all for improving the Solaris packaging technology. But I don't > beleive these problems will be fixed, no matter how much improvement is > made in the packaging tools, or file formats. I wasn't suggesting packaging technology was a solution to this. > Also I think most dependency problems that can be fixed by re-packaging, > can be fixed today with the current pacakging tools. It just takes a > finer resolution of packges, and likely an explosion in the number of > packages. The problems in the packaging, and the problems being solved > in the packaging tools I think, are largely ( though maybe not entirely) > orthogonal, and unrelated. Didn't I just say the problem is the packaging? -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 9:38 AM, James Carlson <[EMAIL PROTECTED]> wrote: > Shawn Walker writes: > > I still do not believe that something cannot be done to address the issue. > > At least in some cases, the "something" would have to be an assumption > that the unresolvable differences are simply unimportant and will > either have no effect on users or will have effects that we just don't > care about. While that is a possible conclusion, I haven't seen the people involved coming to that conclusion so far. -- Shawn Walker, Software and Systems Analyst http://binarycrusader.blogspot.com/ "To err is human -- and to blame it on a computer is even more so." - Robert Orben ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Software Change was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: > On Feb 6, 2008 6:02 AM, Joerg Schilling > <[EMAIL PROTECTED]> wrote: > >> "Shawn Walker" <[EMAIL PROTECTED]> wrote: >> >> No. You mistaken. We didn't change anything related to core libraries and applications. Changes only related to packaging but than again, packaging supposed to be changed, or otherwise what is the value behind any of distribution derivatives? >>> No, I am not mistaken. Just because you didn't change the existing >>> userland, but added to it, makes you divergent. >>> >>> Remember that ON is a bundle of *all* the userland. >>> >> Not true: ON contians e.g. parts of the "new" volume mamagement system only. >> >> You mistaken again - SVR4 packaging is well supported (or at least we try to be compatible here) option for us. *And* it is NOT part of ON. >>> No I am not. IPS != SVR4 packaging. >>> >>> I suspect IPS will eventually be part of ON. When that happens and as >>> SVR4 is phased out, that will make Nexenta very divergent in terms of >>> packaging. >>> >> To be correct, if Indiana introduces a different packaging system, it is >> Indiana that introduces divergence. >> > > Really Joerg; that's just silly. Sun is the one spending time and > money on Indiana and obviously plans to see it incorporated into > Solaris. > > "Indiana" isn't introducing divergence; at least none relevant to this thread. > > I think an analogy that might clear up what indiana is or isn't might be to think of it like the concept cars some car makers send to to car shows. You probably won't ever see that same exact car for sale in a dealer, but you may see (over varying periods of time) different features, most likely refined, and possibly even hard to recognize, from them appear in the regular models that are later available for sale. Indiana to me sounds like a testing ground for several projects to make early access available to the community to what they are doing. Each of these projects I imagine will integrate (or not) into Sun's Solaris at varying points in the future, and the ARC reviews may or may not require them to end up different than they appear in indiana. I'm alright with this. It's good to have an experimental playground for new things to be tried. I'm confident that the ARC will do it's job well, when integration comes around for each project. If there's one thing I've always thought Sun did well with Solaris (and my major objection to linux) it's the real engineering, and architecture, thought, consideration, and review that goes into Solaris. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] xscreensaver (was: [osol-announce] No update on SXCE Build 79)
[EMAIL PROTECTED] (Joerg Schilling) wrote:
> [EMAIL PROTECTED] wrote:
>
> >
> >
> > A simple truss command reveals that xscreensaver opens your DISPLAY with
> > an euid of 0:
> >
> > 15560: execve("/usr/openwin/bin/xscreensaver", 0xFFBFEF3C, 0xFFBFEF44)
> > argc = 1
> > 15560: *** SUID: ruid/euid/suid = 21782 / 0 / 0 ***
> > 15560: access("/home/casper/.Xauthority", R_OK)= 0
> > 15560: open("/home/casper/.Xauthority", O_RDONLY) = 4
> > 15560: getuid()= 21782 [0]
> > 15560: getuid()= 21782 [0]
>
>
> And exactly because of this fact, it does not work.
In case you don't know what I am talking about, here is the correct truss
output:
...
munmap(0xFE9E, 32768) = 0
access("/net/u/jes/.Xauthority", R_OK) Err#13 EACCES <--- This XXX
Xlib: connection to "write(2, " X l i b : c o n n e c".., 21) = 21
:0.0write(2, " : 0 . 0", 4) = 4
" refused by server
Xlib: write(2, " " r e f u s e d b y".., 27)= 27
No protocol specified
write(2, " N o p r o t o c o l ".., 22) = 22
root is not allowed to open ~/.Xauthority because it is mode 0600,
this is the problem with xscreensaver.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
> Chris Linton-Ford writes: > > It might be helpful to consider the shells' dual nature as a) a > > scripting medium and b) an interactive environment. Surely there is no > > engineering reason why a shell could not be coded to have only a strict > > superset of /sbin/sh's commands, thus making scripts compatible. > > What's the superset of this? > > $ /sbin/sh -c 'foo=a; echo b | read foo; echo $foo' > a > $ /usr/bin/ksh93 -c 'foo=a; echo b | read foo; echo $foo' > b > If ksh93 is incompatible with the existing sh *by design*, then nothing can be done that will not step on someones toes somewhere. This pretty much invalidates it as a candidate for a sh replacement. So unless there's a shell out there which does the strict command supersetting and also has the improved interactive usability we're looking at new code. The question is where to put it? Do we fork the /sbin/sh code for Indiana and call it something else, or campaign for features to be included in the "official" Sun sh release? IMHO what Jorg has done with the linking to bsh code to extend sh seems like an eminently sensible way to walk the line between usability and compatibility. Chris ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Software Change was Re: [osol-announce] No update on SXCE Build 79
Shawn Walker wrote: > On Feb 6, 2008 4:44 AM, Joerg Schilling > <[EMAIL PROTECTED]> wrote: > >> "Shawn Walker" <[EMAIL PROTECTED]> wrote: >> >> You need to install GNOME libs in order to run a X-less base OpenSolaris installation. Do you believe this is correct? >>> No, but I suspect it's a result of packaging, not software. >>> >> If this should read that you believe it is not correct, I concur... >> > > Yes, I don't think one should need GNOME libs in order to run an > X-less base installation -- as long as DBUS and HAL are rightfully not > considered "GNOME libs"; since they are not in the relevant sense. > > Agreed. It was just an example of how bad things can get when dependencies aren'ta primary consideration during integration. >> There are general structural problems with the arbitrary "project boundaries" >> that should be fixed in future. If I did put parts of the cdrtools source >> into >> a separate package that you need to doenload from a different location, >> people >> would be angry with me >> > > Yes, I am trying to say that packaging is the issue here, not software. > > No. Dependencies are the issue. Many dependencies are created when the code is written. And some dependencies won't be fixable by changing the packaging. Dependencies need to be considered during development, not after. Hard thought needs to be put into what the use case of a package might be, and both how reasonable it is to require another package in that case, and what problems requiring the other package may cause. I'm all for improving the Solaris packaging technology. But I don't beleive these problems will be fixed, no matter how much improvement is made in the packaging tools, or file formats. Also I think most dependency problems that can be fixed by re-packaging, can be fixed today with the current pacakging tools. It just takes a finer resolution of packges, and likely an explosion in the number of packages. The problems in the packaging, and the problems being solved in the packaging tools I think, are largely ( though maybe not entirely) orthogonal, and unrelated. -Kyle ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
Chris Linton-Ford writes: > It might be helpful to consider the shells' dual nature as a) a > scripting medium and b) an interactive environment. Surely there is no > engineering reason why a shell could not be coded to have only a strict > superset of /sbin/sh's commands, thus making scripts compatible. What's the superset of this? $ /sbin/sh -c 'foo=a; echo b | read foo; echo $foo' a $ /usr/bin/ksh93 -c 'foo=a; echo b | read foo; echo $foo' b Shawn Walker writes: > I still do not believe that something cannot be done to address the issue. At least in some cases, the "something" would have to be an assumption that the unresolvable differences are simply unimportant and will either have no effect on users or will have effects that we just don't care about. -- James Carlson, Solaris Networking <[EMAIL PROTECTED]> Sun Microsystems / 35 Network Drive71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] xscreensaver (was: [osol-announce] No update on SXCE Build 79)
[EMAIL PROTECTED] wrote:
>
>
> A simple truss command reveals that xscreensaver opens your DISPLAY with
> an euid of 0:
>
> 15560: execve("/usr/openwin/bin/xscreensaver", 0xFFBFEF3C, 0xFFBFEF44) argc
> = 1
> 15560: *** SUID: ruid/euid/suid = 21782 / 0 / 0 ***
> 15560: access("/home/casper/.Xauthority", R_OK)= 0
> 15560: open("/home/casper/.Xauthority", O_RDONLY) = 4
> 15560: getuid()= 21782 [0]
> 15560: getuid()= 21782 [0]
And exactly because of this fact, it does not work.
Jörg
--
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED](uni)
[EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] xscreensaver (was: [osol-announce] No update on SXCE Build 79)
A simple truss command reveals that xscreensaver opens your DISPLAY with
an euid of 0:
15560: execve("/usr/openwin/bin/xscreensaver", 0xFFBFEF3C, 0xFFBFEF44) argc =
1
15560: *** SUID: ruid/euid/suid = 21782 / 0 / 0 ***
15560: access("/home/casper/.Xauthority", R_OK)= 0
15560: open("/home/casper/.Xauthority", O_RDONLY) = 4
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: getuid()= 21782 [0]
15560: seteuid(21782) = 0
Casper
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
"Shawn Walker" <[EMAIL PROTECTED]> wrote: > On Feb 6, 2008 5:32 AM, Joerg Schilling > <[EMAIL PROTECTED]> wrote: > > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > > > Yes, but Nexenta is clearly trying to compete; they produce a > > > commercial product. > > > > > > Thus, I stand by the claim that Nexenta, at the very least, is a fork. > > > > The fact whether or not a project is commercial cannot be an indication > > for a fork. > > I was responding to another poster's implication that, to be a fork, a > project has to compete, and Nexenta is definitely competing (I > consider that a good thing). competing is not a reason for calling something a "fork". Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] xscreensaver (was: [osol-announce] No update on SXCE Build 79)
Alan Coopersmith <[EMAIL PROTECTED]> wrote: > > A cannot call this a "solution" as it does not work for me the way it is > > delivered > > in SXCE-77. > > > > If you do make things suid root for "good reason", you should also modify > > the > > source to try again with euid == uid after the attempt to read > > ~/.Xauthority failed. > > The upstream is already setuid root, so we shouldn't have to modify a thing > there, and I believe it already does call XOpenDisplay() as the uid (the > program doesn't read .Xauthority, XOpenDisplay() in libX11 does). It's been > a while since I've looked at the xscreensaver code to confirm that though. > > Virtually every home directory in Sun is NFS mounted, and yet it works for us, > so it's not as simple an issue as you describe. Nonetheless, since you > haven't filed a bug, the xscreensaver maintainer (not me) has no way of > knowing it's not working for you, and thus won't be fixing it until someone > reports a bug. I don't know _why_ it works for you. It definitely does not work for me. I have Solaris Express Community Edition snv_77 X86 Copyright 2007 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 06 November 2007 and my home dir is mounted via NFSv4 from a Netapp machine. A possible explanation why you don't see problems although there are problems may be: - You mount your home via NFSv3 - You read ~/Xauthority as "user" before starting xscrensaver - xscrensaver later gets the locally cached NFSv3 data _even_ _though_ it runs as root Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Software Change was Re: [osol-announce] No update on SXCE Build 79
On Feb 6, 2008 1:03 PM, Shawn Walker <[EMAIL PROTECTED]> wrote: > On Feb 6, 2008 6:02 AM, Joerg Schilling > > <[EMAIL PROTECTED]> wrote: > > > "Shawn Walker" <[EMAIL PROTECTED]> wrote: > > > Since Indiana seeks to change Solaris itself; no. Especially since Sun > > > is the one primarily developing Indiana. > > > > Indiana is a fork from Solaris. > > I don't think accepts different paths of development primarily > performed by those employed by the same company to be "forks." > > That would be rather silly. > > That's like saying Vista is a fork of XP, or some bizarre thing like that. > I wouldn't think it's silly, where I work forks occur all the time ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] [osol-announce] No update on SXCE Build 79
Chris Linton-Ford <[EMAIL PROTECTED]> wrote: > It might be helpful to consider the shells' dual nature as a) a > scripting medium and b) an interactive environment. Surely there is no > engineering reason why a shell could not be coded to have only a strict > superset of /sbin/sh's commands, thus making scripts compatible. > > The interactive usability features are somewhat orthogonal to the > scripting capabilities and compatibility - I'm thinking that what most > people want, and certainly what I want, is improvement to former, rather > than incompatible extensions to the latter. This is what I did on SchilliX-0.6.1 ;-) Jörg -- EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin [EMAIL PROTECTED](uni) [EMAIL PROTECTED] (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
