Re: [osol-discuss] Re: Project Proposal: Next Generation Web Stack
On Tuesday 20 March 2007 11:11 am, Matt Ingenthron wrote: Agreed, and at some level or another, this project will just be packaging what the community around the given component develops, bug for bug complete. I suspect users will understand that already, though it doesn't obviate the need to communicate it. You would think so, but don't ever underestimate the ignorance of the user, they will always astound you!g This is all the more reason the OpenSolaris project community input is important. Absolutely. I feel we need this type of software, yet at the same time see it as a double edge sword. I was considering running some PHP software on a public site, but now I'm not sure. Anyone in the community that really works with PHP on a regular basis and can comment on how they handle the security issues and/or updates? It is my understanding that many modules will not compile on different releases of PHP. Not sure how much of a problem it is to update though. -- Alan DuBoff - Solaris x86 Engineering - IHV/OEM Group Advocate of insourcing at Sun - hire people that care about our company! ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Opensolaris and IPTV
Is it possible to look IPTV with Opensolaris. (wwitv.com) Martti This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: joining Sun
On Tuesday 20 March 2007 08:17 pm, P SRINIVASA RAO wrote: its very nice, to see u here, I am also new to solaris, now I am assured to get a stable version of solaris, under your supervision. Ouch, many of my colleagues will most likely be hurt by that comment. Considering that Solaris is probably one of the most stable operating systems, historically, it's sad to see such a comment. I will personally be watching to see how things change, but one person historically has not been able to change things too drastically. Out of curiousity, what gives you the feeling of assurance knowing that Ian is at Sun, that you didn't have before you knew he was here? Many people know what most of the problems are, and even Solaris Engineering is working on several of those as we type...install, packaging, open source consolidating out of /usr/sfw, etc... I'm anxious to hear what Ian has to say once he has some time to look at things. Would like to hear him talk about some of his Solaris experience as of recent, and/or what type of hardware he's running Solaris on, what issues if any he had during install, how it's performed for him, etc... Wouldn't it be ironic to find out he was using Solaris for all of the LSB work he's been involved with, for instance? -- Alan DuBoff - Solaris x86 Engineering - IHV/OEM Group Advocate of insourcing at Sun - hire people that care about our company! ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Opensolaris and IPTV
Martti Hamunen wrote: Is it possible to look IPTV with Opensolaris. (wwitv.com) It depends which format is being streamed. If real player can play it, you should be OK. Ian ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Opensolaris and IPTV
Martti Hamunen wrote: Is it possible to look IPTV with Opensolaris. (wwitv.com) Martti This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org I will assume you are referring to the Solaris Express distribution. Depending on what format each feed is. If it is Real Video then it may work. If the feed is using Microsoft Video format then you may need to install something like the following mplayer, mplayer-plugin for Firefox, and some video codecs. Doug ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] What is OpenSolaris success?
On Tuesday 20 March 2007 11:43 pm, James Mansion wrote: Shuttleworth has illustrated how much value there is in strong mangement and leadership, and my concern is that by trying to join the 'developer lead' ranks of 'just show me the code' cowboys Solaris will lose. You don't give Solaris any merit on it's technical value and stability, huh? What about some of the state of the art technology, like DTrace, or ZFS, for instance? I mean it should be easy for folks to copy a 128-bit filesystem, Sun even put the code out there, so it shouldn't be hard to reverse engineer, you can look at the code. Adding some probes can't be that hard to a bunch of libraries, can it? Well, look at System T(r)ap, and how long as the Linux community been working on that? Linux development in the first of these has tended towards professional now, by companies with vested interests. Some of the companies doing this are Sun's competitors and won't contribute to Solaris on any basis because of brand association. Really??? Like which companies? The interest I see is quite amazing, companies that some folks would have never dreamed would take an interest in Solaris/OpenSolaris seem to be showing it. Yes, practical people. Make sure that Solaris is very directly aligned with their needs. It is aligned with the current user base, most of them seem content to run Solaris. Many of the new users of Solaris are now seeing enough change that we see them changing to use Solaris. In fact, there are quite a few cases where people migrate from Linux to Solaris due to stability problems and/or binary compatibility. Be careful - do you really mean to imply that my expectation of an open source product should be lower than it would be otherwise? Is that what Open Solaris is about? No, I think you missed the point. -- Alan DuBoff - Solaris x86 Engineering - IHV/OEM Group Advocate of insourcing at Sun - hire people that care about our company! ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Video Problem in SX59
Just installed SXCE 59 on a nVidia/Athlon64 system. (I know there are quite a few problems, but I wanted to check this build out mainly to see whether the Chinese locale problems have been corrected). Keep getting video out of range message-- thus no screen. Booted into failsafe mode, tried to do a svccfg but got the error message that it couldn't match the x11-server pattern. Is there anyway to enter a grub boot parameter to set a workable screen resolution? Also, what's the new grub parameter to boot into a 32-bit kernel (the old parameter kernel/unix doesn't work on Build 59). Thanks. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: joining Sun
The next big bang may be: Jörg Schilling is joining Debian. Everything seems possible ;) Somehow I seriously doubt that. Jörg showed Debian on number of occassions how crappy the Linux code was, especially the SCSI implementation, delivered patches... instead of embracing him with open arms, they hated him for that. And of course the fact he pretty much told them what he taught of the GPL didn't bring any love either. It's a classic. Boy am I glad Jörg's a Solaris fan, and I really mean that. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: joining Sun
On Wed, 21 Mar 2007, UNIX admin wrote: The next big bang may be: Jörg Schilling is joining Debian. Everything seems possible ;) Somehow I seriously doubt that. Jörg showed Debian on number of occassions how crappy the Linux code was, especially the SCSI implementation, delivered patches... instead of embracing him with open arms, they hated him for that. And of course the fact he pretty much told them what he taught of the GPL didn't bring any love either. It's a classic. Stranger things have happened in the Solaris/Sun world. Think of Motif ? Over my dead body ... and similar flying-pig things. Who'd have thought ten years ago that Solaris might become opensourced ? There are a lot of hotheads in the technical crowd, passion seems to be an unavoidable side-effect of technical competency. Once technical alignment is found, though, these outbreaks of temper usually die down as quickly as they came. I don't like missionaries either, but not every Debianista is such a missionary, and Joerg isn't unless you deliberately play the religious card with him. FrankH. Boy am I glad Jörg's a Solaris fan, and I really mean that. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Video Problem in SX59
Just installed SXCE 59 on a nVidia/Athlon64 system. (I know there are quite a few problems, but I wanted to check this build out mainly to see whether the Chinese locale problems have been corrected). Keep getting video out of range message-- thus no screen. Booted into failsafe mode, tried to do a svccfg but got the error message that it couldn't match the x11-server pattern. Is there anyway to enter a grub boot parameter to set a workable screen resolution? Also, what's the new grub parameter to boot into a 32-bit kernel (the old parameter kernel/unix doesn't work on Build 59). Thanks. Thanks to an instant private help from Casper, I was able to boot into the 32-bit mode. Thereafter, I did the svccfg command per Alanc's tutorial. Now I am able to smoothly boot into SX59 as if nothing had happened. Now back to my main issue. The derogatory language associated with the traditional Chinese locale has not been corrected. I went back to Build 55b, it was OK there. Apparently someone sneaked in this change in Build 56. As it stands now, Solaris Express will be banned in Taiwan ( Sun will be publicly persecuted if someone makes a big deal out of it). I am sure this is an inadvertent error. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Video Problem in SX59
Now back to my main issue. The derogatory language associated with the traditional Chinese locale has not been corrected. I went back to Build 55b, it was OK there. Apparently someone sneaked in this change in Build 56. As it stands now, Solaris Express will be banned in Taiwan ( Sun will be publicly persecuted if someone makes a big deal out of it). I am sure this is an inadvertent error. Could you elaborate (in private mail, if you think that is more appropriate) Casper ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Preview of Two Solaris Books
嗯，买了Solaris Internals 2nd 正在看，确实很有用，不知Solaris Performance and Tools 国内什么时候出，去年好像听说ERI在翻译？ This message posted from opensolaris.org___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Preview of Two Solaris Books
Ryan Chang wrote: 嗯，买了Solaris Internals 2nd 正在看，确实很有用，不知Solaris Performance and Tools 国内什么时候出，去年好像听说ERI在翻译？ Hi Ryan, Thanks for your concerns. The Chinese edition of Solaris Internals 2nd will publish by this June in Mainland China. Please keep tuned with the book list on http://www.china-pub.com Best regards, Joey This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
blastwave package handling [was Re: [osol-discuss] Re: joining Sun]
Jason Ozolins writes: Blastwave package upgrade == package remove followed by package install. Not like, say, RPM's handing of upgrades at all. The service stops while the upgrade happens. Not to mention, some of our config files got creamed (this is really the packager's problem rather than inherent in SVR4 packages). This kind of explains why Sun puts out _patches_ rather than new versions of packages - because applying the latter can't be done easily to a running OS instance. SVR4 package management just wasn't designed to work the way that people expect package management to work these days. Not true on both counts. A Solaris upgrade (as opposed to patches) uses packages. The difference is that the upgrade process uses SVr4 'admin' files when necessary. Blastwave could do this with instance=overwrite, and probably should, but it doesn't. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.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
[osol-discuss] Update Manager Freezes
Hi all, I installed opensolaris SunOS unknown 5.11 snv_59 i86pc i386 i86pc everything seems to work except when I try register the update manager seem to freeze. I checked the user and password everything is correct and should work. Pardon me for any mistakes since I'm new to Solaris. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: joining Sun
On Mar 21, 2007, at 04:46, Artem Kachitchkine wrote: Alan DuBoff wrote: On Tuesday 20 March 2007 02:59 pm, Nicolas Linkert wrote: That's really good news. The next big bang may be: Jörg Schilling is joining Debian. Everything seems possible ;) Ah, now it's all making sense...I did note he had some good things to say about Debian in his OGB podcast, maybe Joerg was preparing us for the news that he is joining Debian...LOL! Now, y'all boys realize what this leads to. Simon joining MSFT. Don't make me say it! Wait, I just said it... Owh. They stopped calling a year or so ago... S. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: blastwave package handling [was Re: [osol-discuss] Re: joining Sun]
James Carlson wrote: Jason Ozolins writes: Blastwave package upgrade == package remove followed by package install. Not like, say, RPM's handing of upgrades at all. The service stops while the upgrade happens. Not to mention, some of our config files got creamed (this is really the packager's problem rather than inherent in SVR4 packages). This kind of explains why Sun puts out _patches_ rather than new versions of packages - because applying the latter can't be done easily to a running OS instance. SVR4 package management just wasn't designed to work the way that people expect package management to work these days. Not true on both counts. A Solaris upgrade (as opposed to patches) uses packages. The difference is that the upgrade process uses SVr4 'admin' files when necessary. Blastwave could do this with instance=overwrite, and probably should, but it doesn't. But overwriting with new packages will leave files around that have been removed from the new version of the package. So the packager will have to have additional mechanisms to detect redundant files and remove them. Regards, Moinak. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] apt-get functionality (Was joining Sun)
On Mon, 19 Mar 2007, Alan DuBoff wrote: On Monday 19 March 2007 05:13 pm, David Lloyd wrote: Joe, Indeed, apt-get for Solaris would be quite useful :P Isn't that Nexenta? Had to say it. I don't want the Ubuntu Userland on an OpenSolaris code base. I'd prefer a distribution as close to Sun's release of Sun Solaris (tm) that I can get but without Sun Solaris', errrm, wonderful? package management. Why do you care about the packaging system, if it works? IOW, do you really care about what type of package is used if packaging in Solaris worked as it should, with dependencies resolving properly? I don't think you really care about .deb packages either, what I *think* you're saying is give me a packaging system that works like apt does!, But that just brings us back to Joe's original point: Isn't that Nexenta? Note the Nexenta project is by all rights and intentions (Erast, correct me if I'm wrong) a project of and by the OpenSolaris community. (Question for the future OGB: does a Project/Community have to be hosted on opensolaris.org in order to qualify its members for Core Contributor status?) Eric if I understand you correctly. I'm in agreement with you, if that is what you meant, and packaging is being looked at inside (Open)Solaris Engineering. I will be right in line behind you for a packaging system that works with proper dependency resolution, as apt does with Debian. I want to be able to install over the net also as apt has done for the past number of years. Between the Caiman project and the Packaging, we'll be much closer if not there in the future. Check out the Installation and Packaging Community, if you haven't yet. http://www.opensolaris.org/os/community/install/ -- Alan DuBoff - Solaris x86 Engineering - IHV/OEM Group Advocate of insourcing at Sun - hire people that care about our company! ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: blastwave package handling [was Re: [osol-discuss] Re: joining Sun]
Moinak Ghosh writes: A Solaris upgrade (as opposed to patches) uses packages. The difference is that the upgrade process uses SVr4 'admin' files when necessary. Blastwave could do this with instance=overwrite, and probably should, but it doesn't. But overwriting with new packages will leave files around that have been removed from the new version of the package. So the packager will have to have additional mechanisms to detect redundant files and remove them. Yes; that's what the 'package history' mechanism is about in Solaris upgrades. It is more complicated than I suggested, and I think there's likely an RFE or two buried in here. In any event, it's not really why we use patches. Patches represent an atomic change to objects in multiple packages at once. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.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: blastwave package handling [was Re: [osol-discuss] Re: joining Sun]
Jason Ozolins writes: Blastwave package upgrade == package remove followed by package install. Not like, say, RPM's handing of upgrades at all. The service stops while the upgrade happens. Not to mention, some of our config files got creamed (this is really the packager's problem rather than inherent in SVR4 packages). This kind of explains why Sun puts out _patches_ rather than new versions of packages - because applying the latter can't be done easily to a running OS instance. SVR4 package management just wasn't designed to work the way that people expect package management to work these days. Not true on both counts. A Solaris upgrade (as opposed to patches) uses packages. The difference is that the upgrade process uses SVr4 'admin' files when necessary. Blastwave could do this with instance=overwrite, and probably should, but it doesn't. Well let's take a look at this a bit closer. suppose we have a package called CSWfoo and the package prototype file looks like this : i pkginfo i depend i copyright d none bin 0755 root bin f none bin/foo 0755 root bin f none bin/bar 0755 root bin d none share 0755 root bin d none share/foo 0755 root bin f none share/bar/foo.dat 0444 root other We create a package and then roll it out. We then need to release an update which replaces the bin/foo binary as well as the share/foo file but affects nothing else. In a perfect world this would be a patch and not a package. At some point in the future another release comes along which now includes the amazing upgrade called foobar and its also specially built for AMD64 Opteron's as well as ye old 386 and the pentium_pro. What does the prototype file look like now ? i pkginfo i depend i copyright d none bin 0755 root bin f none bin/foo 0755 root bin f none bin/bar 0755 root bin f none bin/foobar 0755 root bin f none bin/amd64/foobar 0755 root bin f none bin/pentium_pro/foobar 0755 root bin f none bin/i486/foobar 0755 root bin d none share 0755 root bin d none share/foo 0755 root bin f none share/bar/foo.dat 0444 root other So now we have some new binaries, some data files that have not changed, some binaries that are the same again. Patch or Package ? The current method we employ is to remove the whole collection and use the standards compliant SVR4 tools to achieve this. Then install the new package entirely and then move on. The question on the table that needs to be looked at would be is this optimal or even reasonable? Dennis Clarke [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: blastwave package handling [was Re: [osol-discuss] Re: joining Sun]
Dennis Clarke wrote: Jason Ozolins writes: Blastwave package upgrade == package remove followed by package install. Not like, say, RPM's handing of upgrades at all. The service stops while the upgrade happens. Not to mention, some of our config files got creamed (this is really the packager's problem rather than inherent in SVR4 packages). This kind of explains why Sun puts out _patches_ rather than new versions of packages - because applying the latter can't be done easily to a running OS instance. SVR4 package management just wasn't designed to work the way that people expect package management to work these days. Not true on both counts. A Solaris upgrade (as opposed to patches) uses packages. The difference is that the upgrade process uses SVr4 'admin' files when necessary. Blastwave could do this with instance=overwrite, and probably should, but it doesn't. Well let's take a look at this a bit closer. suppose we have a package called CSWfoo and the package prototype file looks like this : i pkginfo i depend i copyright d none bin 0755 root bin f none bin/foo 0755 root bin f none bin/bar 0755 root bin d none share 0755 root bin d none share/foo 0755 root bin f none share/bar/foo.dat 0444 root other We create a package and then roll it out. We then need to release an update which replaces the bin/foo binary as well as the share/foo file but affects nothing else. In a perfect world this would be a patch and not a package. At some point in the future another release comes along which now includes the amazing upgrade called foobar and its also specially built for AMD64 Opteron's as well as ye old 386 and the pentium_pro. What does the prototype file look like now ? i pkginfo i depend i copyright d none bin 0755 root bin f none bin/foo 0755 root bin f none bin/bar 0755 root bin f none bin/foobar 0755 root bin f none bin/amd64/foobar 0755 root bin f none bin/pentium_pro/foobar 0755 root bin f none bin/i486/foobar 0755 root bin d none share 0755 root bin d none share/foo 0755 root bin f none share/bar/foo.dat 0444 root other So now we have some new binaries, some data files that have not changed, some binaries that are the same again. Patch or Package ? The current method we employ is to remove the whole collection and use the standards compliant SVR4 tools to achieve this. Then install the new package entirely and then move on. The question on the table that needs to be looked at would be is this optimal or even reasonable? Dennis Clarke [EMAIL PROTECTED] Everyone who thinks he can improve something should go ahead and JOIN BLASTWAVE. Or build up his own stack. Rather than complaining on public lists. Martin Bochnig [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: blastwave package handling [was Re: [osol-discuss] Re: joining Sun]
Yes; that's what the 'package history' mechanism is about in Solaris upgrades. It is more complicated than I suggested, and I think there's likely an RFE or two buried in here. In any event, it's not really why we use patches. Patches represent an atomic change to objects in multiple packages at once. The other issue that arises here is that a patch has a dependency tree also. If I have a package that requires only a few small changes then a patch makes sense. If I then make another release with a few more changes then we have yet another patch. However these patches now depend on previous editions of the patch. In order to get an upto date Apache we need the patch today to include all the patch changes from previous patches in a summative way ( if there is such a term ) and we need to be able to go from a five year old Apache to todays Apache in one fell swoop with the grand unified patch. [ take a deep breath here ] the complete removal of a package releases the user from any burden of trackign patches at all. The user simply does a pkg-get -u apache and then the job is done. Even if they are two years out of date. Dennis Clarke [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: blastwave package handling [was Re: [osol-discuss] Re: joining Sun]
Dennis Clarke writes: So now we have some new binaries, some data files that have not changed, some binaries that are the same again. Patch or Package ? It can be either. The current method we employ is to remove the whole collection and use the standards compliant SVR4 tools to achieve this. Then install the new package entirely and then move on. The question on the table that needs to be looked at would be is this optimal or even reasonable? Right. I think a better strategy would be to deal with instance=overwrite, but that does mean either contributing Install fixes to allow automatic removal of abandoned files or something akin to the upgrade-related package history file. (I think having the ability to do something like omitted=remove in the admin(4) file to mean any files that were in the old pkgmap for this package, but are omitted from the new pkgmap should be removed from the system would be helpful.) -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.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: blastwave package handling [was Re: [osol-discuss] Re: joining Sun]
Martin Bochnig writes: Everyone who thinks he can improve something should go ahead and JOIN BLASTWAVE. Or build up his own stack. Rather than complaining on public lists. If we can't even discuss the issues on a public list, how exactly do you propose that we end up working together on anything? Do you have something useful to contribute, or are you just complaining? -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.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: blastwave package handling [was Re: [osol-discuss] Re: joining Sun]
Dennis Clarke writes: The other issue that arises here is that a patch has a dependency tree also. If I have a package that requires only a few small changes then a patch makes sense. If I then make another release with a few more changes then we have yet another patch. However these patches now depend on previous editions of the patch. In order to get an upto date Apache we need the patch today to include all the patch changes from previous patches in a summative way ( if there is such a term ) and we need to be able to go from a five year old Apache to todays Apache in one fell swoop with the grand unified patch. Right; you would need to deal with the complex and undocumented issues related to patching. I would not recommend attempting to deliver these things by way of patches. The original question, though was about whether Sun uses patches to avoid the package remove/install design pattern, and that's not quite the case. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.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
[osol-discuss] Re: blastwave package handling
Dennis Clarke writes: The other issue that arises here is that a patch has a dependency tree also. If I have a package that requires only a few small changes then a patch makes sense. If I then make another release with a few more changes then we have yet another patch. However these patches now depend on previous editions of the patch. In order to get an upto date Apache we need the patch today to include all the patch changes from previous patches in a summative way ( if there is such a term ) and we need to be able to go from a five year old Apache to todays Apache in one fell swoop with the grand unified patch. Right; you would need to deal with the complex and undocumented issues related to patching. I would not recommend attempting to deliver these things by way of patches. The original question, though was about whether Sun uses patches to avoid the package remove/install design pattern, and that's not quite the case. We do have a good line of discussion here that needs to be looked at. Or at the very least we can draw things on a whiteboard and see if there if a Grand Unified Theory of package maintainance where we respect the old rules ( like Newtonian Physics ) but also handle a better way of thinking, like Quantum Physics. I just hope that we don't end up looking for Schodingers cat and then find out that the patch worked and the cat is in fact, quite dead. I have no idea if anyone can follow my puns so I'll be more clear. Do you feel or even think that we can come up with a way to maintain the contents database file as well as perhaps design a better way to roll out software packages? That is a loaded multi-level sort of question and a good way to start. Dennis ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: blastwave package handling [was Re: [osol-discuss] Re: joining Sun]
James Carlson wrote: Martin Bochnig writes: Everyone who thinks he can improve something should go ahead and JOIN BLASTWAVE. Or build up his own stack. Rather than complaining on public lists. If we can't even discuss the issues on a public list, how exactly do you propose that we end up working together on anything? ??? Somebody (not directly you) started complaining about Blastwave. Unfortunately not in a too constructive manner (in contrast to what you had done [at least _before_ you wrote me this very mail]). It felt like Blastwave can't do it. And I'm sure, such a statement hurts all the hard working guys investing their resources (at a minimum in form of their money and spare time), only to provide users a FREE SERVICE. Do you have something useful to contribute, or are you just complaining? And no, I cannot contribute anything. I'm slightly tired and am burning out (awake and working non-stop 30++ hours). I can just and only complain, but see yourself: Good news: #0.) Sombody has tested marTux on Niagara sun4v and it is reported to boot (only svc trouble, but that also happens on sun4u) #1.) the sunffb driver finally also works inside Xorg 7.2.0 since last night, and now even with hardware accelleration. However, never try to kill or stop it: Forecd hard-reset of host box, due to Fatal cpu error. But except that it works like a charme since just 2 hours ago!! I'm writing this on Creator3D/Blade2k/Xorg7.2.0/Mozilla1.7 :-) Xorg.0.log X Window System Version 7.2.0 Release Date: 22 January 2007 X Protocol Version 11, Revision 0, Release 7.2 Build Operating System: SunOS 5.11 sun4u Current Operating System: SunOS mb1x-ws1 5.11 snv_41 sun4u Build Date: 20 March 2007 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /usr/local/var/log/Xorg.0.log, Time: Wed Mar 21 12:13:34 2007 (==) Using config file: /etc/X11/xorg.conf (==) ServerLayout X.org Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device Card0 (**) |--Screen Screen1 (1) (**) | |--Monitor Monitor1 (**) | |--Device Card1 (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (WW) The directory /usr/local/lib/X11/fonts/TTF/ does not exist. Entry deleted from font path. (WW) The directory /usr/local/lib/X11/fonts/OTF does not exist. Entry deleted from font path. (**) FontPath set to: /usr/local/lib/X11/fonts/misc/, /usr/local/lib/X11/fonts/Type1/, /usr/local/lib/X11/fonts/100dpi/, /usr/local/lib/X11/fonts/75dpi/ (**) RgbPath set to /usr/local/share/X11/rgb (**) ModulePath set to /usr/local/lib/xorg/modules (II) Loader magic: 2b5a18 (II) Module ABI versions: X.Org ANSI C Emulation: 0.3 X.Org Video Driver: 1.1 X.Org XInput driver : 0.7 X.Org Server Extension : 0.3 X.Org Font Renderer : 0.5 (II) Loader running on solaris (II) LoadModule: pcidata (II) Loading /usr/local/lib/xorg/modules//libpcidata.so (II) Module pcidata: vendor=X.Org Foundation compiled for 7.2.0, module version = 1.0.0 ABI class: X.Org Video Driver, version 1.1 (II) Schizo PCI host bridge found (pci108e,8001) (II) Schizo PCI host bridge found (pci108e,8001) (II) PCI: PCI scan (all values are in hex) (II) PCI: 100:00:0: chip 108e,8001 card , rev 00 class 06,00,00 hdr 00 (II) PCI: 100:01:0: chip 1033,0035 card 1033,0035 rev 43 class 0c,03,10 hdr 80 (II) PCI: 100:01:1: chip 1033,0035 card 1033,0035 rev 43 class 0c,03,10 hdr 00 (II) PCI: 100:01:2: chip 1033,00e0 card 0e55,2928 rev 04 class 0c,03,20 hdr 00 (II) PCI: 100:02:0: chip 8086,b555 card 108e,676a rev 03 class 06,80,00 hdr 00 (II) PCI: 100:05:0: chip 108e,1100 card , rev 01 class 06,80,00 hdr 80 (II) PCI: 100:05:1: chip 108e,1101 card , rev 01 class 02,00,00 hdr 80 (II) PCI: 100:05:2: chip 108e,1102 card , rev 01 class 0c,00,10 hdr 80 (II) PCI: 100:05:3: chip 108e,1103 card , rev 01 class 0c,03,10 hdr 80 (II) PCI: 100:06:0: chip 1000,000f card , rev 37 class 01,00,00 hdr 80 (II) PCI: 100:06:1: chip 1000,000f card , rev 37 class 01,00,00 hdr 80 (II) PCI: 200:00:0: chip 108e,8001 card , rev 00 class 06,00,00 hdr 00 (II) PCI: 200:04:0: chip 1077,2200 card , rev 05 class 01,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus [EMAIL PROTECTED]: bridge is at ([EMAIL PROTECTED]:0:0), ([EMAIL PROTECTED],[EMAIL PROTECTED],[EMAIL PROTECTED]), BCTRL: 0x0008 (VGA_EN is set) (II) Bus [EMAIL PROTECTED] I/O range: [0] -1 1 0x - 0x00ff (0x100) IX[B] (II) Bus [EMAIL PROTECTED] non-prefetchable memory range: [0] -1 1 0x - 0x (0x0) MX[B] (II) Bus [EMAIL PROTECTED] prefetchable memory range: [0] -1 1 0x - 0x (0x0) MX[B] (II) Host-to-PCI bridge: (II) Bus
Re: [osol-discuss] Re: blastwave package handling
Dennis Clarke writes: Do you feel or even think that we can come up with a way to maintain the contents database file as well as perhaps design a better way to roll out software packages? Yes. I think it'd be helpful to have a check pkgmap diffs mode for pkgadd, so that can remove stray files after performing an instance=overwrite type of install. One of the benefits is that we could eliminate one of the possible failure modes: at the end of a pkgadd, you'd either have the new package installed, or the old one would remain. It wouldn't be possible to remove the old one and fail to install the new. Another is that it'd be possible to migrate configuration files and the like as software versions change. Right now, we can't know when you do pkgrm whether you'll ever install a new version of the same package, so the best we can do is just leave those files on the system during pkgrm. I think the rough parts are: - Figuring out what to do about older releases, as blastwave supports S8 and up, and we're unlikely to be integrating new pkgadd features there. We need a simple way to fall back to the older remove-and-install scheme. - Deciding what to do about files that move between packages. - Enumerating and handling the other corner cases, such as a package with a previous instance delivering usr/lib/foo, a new instance without usr/lib/foo in its pkgmap, but with a postinstall script that does installf on usr/lib/foo. For the first one, I would propose two things: 1. For packages that don't make reference to the to-be-removed files in preinstall, postinstall, or class action scripts, there's no difference between the two mechanisms. This is, I think, where we are today. 2. For those that end up referring to those files, they'll need to be separated into pre-S11 and post-S11 versions. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.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] Re: blastwave package handling
James Carlson wrote: And btw, I already did say something to that topic, at least a bit: http://www.guug.de/veranstaltungen/osdevcon2007/abstracts.html#4_4_1 http://www.guug.de/veranstaltungen/osdevcon2007/slides/marTux___OSDevCon2007.pdf And Damien Carbery has held a beautiful talk about pkgbuild, recommended: pkgbuild - Building Solaris packages using RPM-like recipes http://www.guug.de/veranstaltungen/osdevcon2007/abstracts.html#4_6_1 by Damien Carbery http://www.guug.de/veranstaltungen/osdevcon2007/abstracts.html#4_6_1 http://www.osdevcon.org/2007/slides/pkgbuild-osdevcon07.pdf ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Update Manager Freezes
The same happens for me and I think others as well. Blame it on a bad build, I think :) This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Video Problem in SX59
I had a problem with video on NV_59 also. I fixed it by downloading and installing the driver from Nvidia. Can you please provide a link to the svccfg command per Alanc's tutorial. Thanks, Ron Halstead This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: blastwave package handling
Martin Bochnig writes: http://www.guug.de/veranstaltungen/osdevcon2007/slides/marTux___OSDevCon2007.pdf [...] http://www.osdevcon.org/2007/slides/pkgbuild-osdevcon07.pdf We were talking about in-place updates of packages, not the means by which packages are constructed. I don't see in either of those references any information about how updates should be handled. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.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] apt-get functionality (Was joining Sun)
On Wed, 2007-03-21 at 08:18 -0500, Eric Boutilier wrote: On Mon, 19 Mar 2007, Alan DuBoff wrote: On Monday 19 March 2007 05:13 pm, David Lloyd wrote: Joe, Indeed, apt-get for Solaris would be quite useful :P Isn't that Nexenta? Had to say it. I don't want the Ubuntu Userland on an OpenSolaris code base. I'd prefer a distribution as close to Sun's release of Sun Solaris (tm) that I can get but without Sun Solaris', errrm, wonderful? package management. Why do you care about the packaging system, if it works? IOW, do you really care about what type of package is used if packaging in Solaris worked as it should, with dependencies resolving properly? I don't think you really care about .deb packages either, what I *think* you're saying is give me a packaging system that works like apt does!, But that just brings us back to Joe's original point: Isn't that Nexenta? Note the Nexenta project is by all rights and intentions (Erast, correct me if I'm wrong) a project of and by the OpenSolaris community. Yes, its entierly driven by the Community developers and users who generates bug reports... We just trying to coordinate the effort and sometimes(when time permits) contribute to the project. Money-wise, it relies on Users donatations and Google adverts. So, if you do not donated yet, please do.. :-) Periodic donations especially appreciated. We also need more build x86 machines to deploy. There are many areas which needs to be improved. ON/NWS better integration is just one of them. We also would like to move GNU/Debian userland to Feisty branch, but this will require 2 engineers 1 month full time, so the hope is that involved Companies(those who trying to use NexentaOS) will donate engineering force for us.. (Question for the future OGB: does a Project/Community have to be hosted on opensolaris.org in order to qualify its members for Core Contributor status?) Eric if I understand you correctly. I'm in agreement with you, if that is what you meant, and packaging is being looked at inside (Open)Solaris Engineering. I will be right in line behind you for a packaging system that works with proper dependency resolution, as apt does with Debian. I want to be able to install over the net also as apt has done for the past number of years. Between the Caiman project and the Packaging, we'll be much closer if not there in the future. Check out the Installation and Packaging Community, if you haven't yet. http://www.opensolaris.org/os/community/install/ -- Alan DuBoff - Solaris x86 Engineering - IHV/OEM Group Advocate of insourcing at Sun - hire people that care about our company! ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: blastwave package handling
James Carlson wrote:
Martin Bochnig writes:
http://www.guug.de/veranstaltungen/osdevcon2007/slides/marTux___OSDevCon2007.pdf
[...]
http://www.osdevcon.org/2007/slides/pkgbuild-osdevcon07.pdf
We were talking about in-place updates of packages, not the means by
which packages are constructed. I don't see in either of those
references any information about how updates should be handled.
It's a question of how a person understands and/or defines things.
I tend to taking into consideration the whole picture.
Also, somebody mentioned RPM earlier in this thread (13 hours ago).
Plus: I doubt you already finished reading all the literature references
(and nested references [and nested references{...}]).
[...]
http://www.osdevcon.org/2007/slides/pkgbuild-osdevcon07.pdf
---\
More info
• http://pkgbuild.sf.net/
• http://pkgbuild.sf.net/spec-files-extra
• http://opensolaris.org/os/project/jds
• http://opensolaris.org/os/project/xfce
---\
http://docs.fedoraproject.org/drafts/rpm-guide-en/ch-intro-packaging.html#id2861153
[...]
Do you suggest, pkgbuild built packages cannot be customized and tweaked
in order to achieve optimum results in terms of your main topic?
maybe they cannot even be upgraded at all, oh - then it was indeed
off-topic.
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: blastwave package handling
Dennis Clarke writes: Dennis Clarke writes: Do you feel or even think that we can come up with a way to maintain the contents database file as well as perhaps design a better way to roll out software packages? Yes. Excellent .. me too. :-) However I can not write up a complete response right away so I want to come back to this in a little while. I have to deal with a few things and then I want to come back to this. OKay ? Sure thing. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.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] Re: blastwave package handling
What if we do something like this: 1. Add parameters to pkgmaps going forward that define certain files as configuration files. These files would normally not be touched during a package upgrade. 2. Add parameters to the pkgmaps that highlight SMF manifests. 3. When a newer version of a package is installed the following happens: - Check if SMF manifest is enabled. If so, disable it. - If the upgrade does not affect configuration parameters, preserve the configuration files. Otherwise, back them up into /var/sadm/pkg/pkg name/backup/conf. Display a message stating the action. - Remove the files being updated and install the new files. - If SMF service was enabled previously and configuration files were preserved, start SMF service. - Update pkg repository with information. As such, these new parameters are only picked up by Nevada and above and the older OS versions can ignore the parameters. That should preserve the legacy behavior. I'm sure this over simplifies the details, but I hope it makes sense. While it would be nice to have an intelligent configuration file merge function in the pkg tools, I don't think it's realistic. --- James Carlson [EMAIL PROTECTED] wrote: Dennis Clarke writes: Do you feel or even think that we can come up with a way to maintain the contents database file as well as perhaps design a better way to roll out software packages? Yes. I think it'd be helpful to have a check pkgmap diffs mode for pkgadd, so that can remove stray files after performing an instance=overwrite type of install. One of the benefits is that we could eliminate one of the possible failure modes: at the end of a pkgadd, you'd either have the new package installed, or the old one would remain. It wouldn't be possible to remove the old one and fail to install the new. Another is that it'd be possible to migrate configuration files and the like as software versions change. Right now, we can't know when you do pkgrm whether you'll ever install a new version of the same package, so the best we can do is just leave those files on the system during pkgrm. I think the rough parts are: - Figuring out what to do about older releases, as blastwave supports S8 and up, and we're unlikely to be integrating new pkgadd features there. We need a simple way to fall back to the older remove-and-install scheme. - Deciding what to do about files that move between packages. - Enumerating and handling the other corner cases, such as a package with a previous instance delivering usr/lib/foo, a new instance without usr/lib/foo in its pkgmap, but with a postinstall script that does installf on usr/lib/foo. For the first one, I would propose two things: 1. For packages that don't make reference to the to-be-removed files in preinstall, postinstall, or class action scripts, there's no difference between the two mechanisms. This is, I think, where we are today. 2. For those that end up referring to those files, they'll need to be separated into pre-S11 and post-S11 versions. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.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 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Octave J. Orgeron Solaris Systems Engineer http://www.opensolaris.org/os/community/sysadmin/ http://unixconsole.blogspot.com [EMAIL PROTECTED] *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Finding fabulous fares is fun. Let Yahoo! FareChase search your favorite travel sites to find flight and hotel bargains. http://farechase.yahoo.com/promo-generic-14795097 ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Web Stack NG Project: Questions for the Community
Hi. The ARC Cases for the WebStack NG Project have been submitted for review (and hopefully approval), and i would like to ask our community's input regarding two important questions which have come up during our discussions: 1. Should the initial components released for this project include the 64-bit bits in the initial Integration ? 2. The currently proposed Apache 2.2.4 integration installs Apache in /usr/apache2, thereby _overwriting_ the existing Apache 2.0.x. Valid arguments have been made pro, and against this approach, with the suggestion that Apache 2.2.4 installs in /usr/apache2.2, thereby preserving the existing /usr/apache2. However, this alternate location would *not* alter the EOF/EOL timeout announced for Apache 2.0.x. What are the community's views on this ? Thank you. --Stefan -- Stefan Teleman Sun Microsystems, Inc. [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Video Problem in SX59
Ron Halstead wrote: I had a problem with video on NV_59 also. I fixed it by downloading and installing the driver from Nvidia. Can you please provide a link to the svccfg command per Alanc's tutorial. The svccfg command is only needed if you haven't installed the new driver from nvidia. It was detailed in the X.Org 7.2 heads up message at: http://www.opensolaris.org/jive/thread.jspa?threadID=24027tstart=0 -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: Traditional Chinese locale bug (was: [osol-discuss] Re: Video Problem in SX59)
W. Wayne Liauh wrote: Now back to my main issue. The derogatory language associated with the traditional Chinese locale has not been corrected. I went back to Build 55b, it was OK there. Apparently someone sneaked in this change in Build 56. As it stands now, Solaris Express will be banned in Taiwan ( Sun will be publicly persecuted if someone makes a big deal out of it). I am sure this is an inadvertent error. [EMAIL PROTECTED] (which I've cc'ed here) is the most efficient way to get the attention of the people responsible for those translations, but without more detail about what you find objectionable (i.e. what wording on what screen/application) I'm not sure what they can do. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
On Wed, 21 Mar 2007, Stefan Teleman wrote: 1. Should the initial components released for this project include the 64-bit bits in the initial Integration ? Desirable, but not mandatory. 2. The currently proposed Apache 2.2.4 integration installs Apache in /usr/apache2, thereby _overwriting_ the existing Apache 2.0.x. Valid arguments have been made pro, and against this approach, with the suggestion that Apache 2.2.4 installs in /usr/apache2.2, thereby preserving the existing /usr/apache2. However, this alternate location would *not* alter the EOF/EOL timeout announced for Apache 2.0.x. What are the community's views on this ? Overwriting the /usr/apache2 that comes on the Solaris media is a no-no, in my opinion, and /usr/apache2.2 just pollutes the /usr namespace even more than it is already. IMHO, the correct place for this is under /opt. I have no strong feelings either way, but I would prefer /opt/apache2 over /opt/apache2.2. -- Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB member CEO, My Online Home Inventory Voice: +1 (250) 979-1638 URLs: http://www.rite-group.com/rich http://www.myonlinehomeinventory.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: blastwave package handling
Martin Bochnig wrote: James Carlson wrote: Man, okay. I didn't hit the nail. Let me finally sllep now, good night! Regards, Martin Bochnig ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] bzip2 and gzip man pages for nv_61
Hi all, New man pages for nv_61 are available, we have released in bzip2 archive format AND gzip archive format based on your feedback. 62 new files and 300 changed files for this build. http://dlc.sun.com/osol/man/downloads/current/ Thanks, Michelle This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
On 21/03/07, Rich Teer [EMAIL PROTECTED] wrote: On Wed, 21 Mar 2007, Stefan Teleman wrote: 2. The currently proposed Apache 2.2.4 integration installs Apache in /usr/apache2, thereby _overwriting_ the existing Apache 2.0.x. Valid arguments have been made pro, and against this approach, with the suggestion that Apache 2.2.4 installs in /usr/apache2.2, thereby preserving the existing /usr/apache2. However, this alternate location would *not* alter the EOF/EOL timeout announced for Apache 2.0.x. What are the community's views on this ? Overwriting the /usr/apache2 that comes on the Solaris media is a no-no, in my opinion, and /usr/apache2.2 just pollutes the /usr namespace even more than it is already. IMHO, the correct place for this is under /opt. I have no strong feelings either way, but I would prefer /opt/apache2 over /opt/apache2.2. I strongly agree with this particular approach. This makes the separation clear and easy. -- Less is only more where more is no good. --Frank Lloyd Wright Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
Shawn Walker wrote:
On 21/03/07, Rich Teer [EMAIL PROTECTED] wrote:
Overwriting the /usr/apache2 that comes on the Solaris media is a no-no,
in my opinion, and /usr/apache2.2 just pollutes the /usr namespace even
more than it is already. IMHO, the correct place for this is under /opt.
I have no strong feelings either way, but I would prefer /opt/apache2
over
/opt/apache2.2.
I strongly agree with this particular approach. This makes the
separation clear and easy.
Please keep in mind that, there are two additional locations for Apache, in
addition to the location of the actual binaries [/{usr,opt}/apache2]:
/etc/apache2
/var/apache2
These additional two locations *must* exist.
--Stefan
--
Stefan Teleman
Sun Microsystems, Inc.
[EMAIL PROTECTED]
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
[osol-discuss] Re: [sfwnv-discuss] Web Stack NG Project: Questions for the Community
Stefan, 2. The currently proposed Apache 2.2.4 integration installs Apache in /usr/apache2, thereby _overwriting_ the existing Apache 2.0.x. Valid arguments have been made pro, and against this approach, with the suggestion that Apache 2.2.4 installs in /usr/apache2.2, thereby preserving the existing /usr/apache2. However, this alternate location would *not* alter the EOF/EOL timeout announced for Apache 2.0.x. Just to clarify, the overwriting we're talking about is of the Apache 2.0.x binaries and libraries (or from a System V packaging perspective, the f files that the vendor - for example, Sun - delivers) and we're not talking about overwriting the configuration files (the so-called e files). Is that correct? dsc ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: [sfwnv-discuss] Web Stack NG Project: Questions for the Community
[EMAIL PROTECTED] wrote: Stefan, 2. The currently proposed Apache 2.2.4 integration installs Apache in /usr/apache2, thereby _overwriting_ the existing Apache 2.0.x. Valid arguments have been made pro, and against this approach, with the suggestion that Apache 2.2.4 installs in /usr/apache2.2, thereby preserving the existing /usr/apache2. However, this alternate location would *not* alter the EOF/EOL timeout announced for Apache 2.0.x. Just to clarify, the overwriting we're talking about is of the Apache 2.0.x binaries and libraries (or from a System V packaging perspective, the f files that the vendor - for example, Sun - delivers) and we're not talking about overwriting the configuration files (the so-called e files). Is that correct? Correct. Existing configuration files will *not* be overwritten. --Stefan -- Stefan Teleman Sun Microsystems, Inc. [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
On Wed, 21 Mar 2007, Stefan Teleman wrote:
Please keep in mind that, there are two additional locations for Apache, in
addition to the location of the actual binaries [/{usr,opt}/apache2]:
/etc/apache2
/var/apache2
These additional two locations *must* exist.
Right, if the Apache on the Solaris media is installed. I believe
/etc/opt/apache2 and /var/opt/apache2 would be the correct locations
for the CoolStack stuff (or any other Apache package that didn't come
with the Solaris media).
--
Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB member
CEO,
My Online Home Inventory
Voice: +1 (250) 979-1638
URLs: http://www.rite-group.com/rich
http://www.myonlinehomeinventory.com
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Video Problem in SX59
I had a problem with video on NV_59 also. I fixed it by downloading and installing the driver from Nvidia. Can you please provide a link to the svccfg command per Alanc's tutorial. Thanks, Ron Halstead First, to boot into the 32-bit kernel (per Casper's instruction): change the grub commands to (pressing e during grub boot): kernel /platform/i86pc/kernel/unix module /platform/i86pc/boot_archive Second, as to Alanc's (single-line) svccfg tutorial: svccfg -s x11-server setprop options/server=/usr/X11/bin/i386/Xorg as per: http://www.opensolaris.org/jive/thread.jspa?threadID=24027tstart=0 Build 59 is very experimental, I don't recommend anyone to use it for productive work. However, it really feels good to see the proprietary nVidia driver being legitimately included in (or integrated with) the kernel--perhaps we are beginning to see the advantage of CDDL. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
Rich Teer wrote: Overwriting the /usr/apache2 that comes on the Solaris media is a no-no, in my opinion, and /usr/apache2.2 just pollutes the /usr namespace even more than it is already. IMHO, the correct place for this is under /opt. I have no strong feelings either way, but I would prefer /opt/apache2 over /opt/apache2.2. These ARC cases are for integration to Solaris, so /opt is inappropriate, and /usr is correct. -- -Alan Coopersmith- [EMAIL PROTECTED] Sun Microsystems, Inc. - X Window System Engineering ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
On 21/03/07, Stefan Teleman [EMAIL PROTECTED] wrote:
Shawn Walker wrote:
On 21/03/07, Rich Teer [EMAIL PROTECTED] wrote:
Overwriting the /usr/apache2 that comes on the Solaris media is a no-no,
in my opinion, and /usr/apache2.2 just pollutes the /usr namespace even
more than it is already. IMHO, the correct place for this is under /opt.
I have no strong feelings either way, but I would prefer /opt/apache2
over
/opt/apache2.2.
I strongly agree with this particular approach. This makes the
separation clear and easy.
Please keep in mind that, there are two additional locations for Apache, in
addition to the location of the actual binaries [/{usr,opt}/apache2]:
/etc/apache2
/var/apache2
These additional two locations *must* exist.
Personally, I don't have a problem with that. Apache configuration can
usually be shared between versions (at least within 2.x versions in
this case) without a problem. It is the binaries that are the bigger
issue (in my view).
I never liked the /etc/opt/apache2, and so on that some distributions
did as sometimes it wasn't clear which apache2 read what configuration
from where, it also made greps by lazy admins (like me) painful ;)
--
Less is only more where more is no good. --Frank Lloyd Wright
Shawn Walker, Software and Systems Analyst
[EMAIL PROTECTED] - http://binarycrusader.blogspot.com/
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
On 21/03/07, Alan Coopersmith [EMAIL PROTECTED] wrote: Rich Teer wrote: Overwriting the /usr/apache2 that comes on the Solaris media is a no-no, in my opinion, and /usr/apache2.2 just pollutes the /usr namespace even more than it is already. IMHO, the correct place for this is under /opt. I have no strong feelings either way, but I would prefer /opt/apache2 over /opt/apache2.2. These ARC cases are for integration to Solaris, so /opt is inappropriate, and /usr is correct. That is something that wasn't clear to me. I was under the impression that these were going to be frequently updated packages provided optionally to the community. I didn't think that Sun was going to update the version in Solaris that often... Apparently I have misread the entire proposal. -- Less is only more where more is no good. --Frank Lloyd Wright Shawn Walker, Software and Systems Analyst [EMAIL PROTECTED] - http://binarycrusader.blogspot.com/ ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
I agree completely. Using /etc/opt/apache2 is confusing and seems overly
complicated to me personally. If we assume that the whole concept behind
the web stack project is ease of use, I think that the whole point is
being missed by adding this much complication to it.
Shawn Walker wrote:
On 21/03/07, Stefan Teleman [EMAIL PROTECTED] wrote:
Shawn Walker wrote:
On 21/03/07, Rich Teer [EMAIL PROTECTED] wrote:
Overwriting the /usr/apache2 that comes on the Solaris media is a
no-no,
in my opinion, and /usr/apache2.2 just pollutes the /usr namespace
even
more than it is already. IMHO, the correct place for this is
under /opt.
I have no strong feelings either way, but I would prefer /opt/apache2
over
/opt/apache2.2.
I strongly agree with this particular approach. This makes the
separation clear and easy.
Please keep in mind that, there are two additional locations for
Apache, in
addition to the location of the actual binaries [/{usr,opt}/apache2]:
/etc/apache2
/var/apache2
These additional two locations *must* exist.
Personally, I don't have a problem with that. Apache configuration can
usually be shared between versions (at least within 2.x versions in
this case) without a problem. It is the binaries that are the bigger
issue (in my view).
I never liked the /etc/opt/apache2, and so on that some distributions
did as sometimes it wasn't clear which apache2 read what configuration
from where, it also made greps by lazy admins (like me) painful ;)
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
On Wed, 21 Mar 2007, Alan Coopersmith wrote: These ARC cases are for integration to Solaris, so /opt is inappropriate, and /usr is correct. Oh in that case, I agree. *Provided* that the CoolStack stuff will replace the current stuff on the Solaris distribution media. -- Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB member CEO, My Online Home Inventory Voice: +1 (250) 979-1638 URLs: http://www.rite-group.com/rich http://www.myonlinehomeinventory.com ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: apt-get functionality (Was joining Sun)
On Wed, 21 Mar 2007, Erast Benson wrote: On Wed, 2007-03-21 at 08:18 -0500, Eric Boutilier wrote: But that just brings us back to Joe's original point: Isn't that Nexenta? Note the Nexenta project is by all rights and intentions (Erast, correct me if I'm wrong) a project of and by the OpenSolaris community. Yes, its entierly driven by the Community developers and users who generates bug reports... We just trying to coordinate the effort and sometimes(when time permits) contribute to the project. Money-wise, it relies on Users donatations and Google adverts. So, if you do not donated yet, please do.. :-) Periodic donations especially appreciated. We also need more build x86 machines to deploy. There are many areas which needs to be improved. ON/NWS better integration is just one of them. We also would like to move GNU/Debian userland to Feisty branch, but this will require 2 engineers 1 month full time, so the hope is that involved Companies(those who trying to use NexentaOS) will donate engineering force for us.. Would it help cost-wise to consider migrating some things? I would think at least some of your apps/DB/mail systems could use the HW/SW infrastructure and bandwidth that opensoloaris.org provides... Eric (Question for the future OGB: does a Project/Community have to be hosted on opensolaris.org in order to qualify its members for Core Contributor status?) ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
On Wed, 21 Mar 2007, Shawn Walker wrote:
I never liked the /etc/opt/apache2, and so on that some distributions
did as sometimes it wasn't clear which apache2 read what configuration
from where, it also made greps by lazy admins (like me) painful ;)
Agreed, which is why the docs actually suggest /{etc,var}/opt/packagename,
for example, /etc/opt/RICHTapache2 and /var/opt/RICHTapache2. Although
the pathname is a bit longer, there can be no confusion as to what package
it's associated with!
--
Rich Teer, SCSA, SCNA, SCSECA, OpenSolaris CAB member
CEO,
My Online Home Inventory
Voice: +1 (250) 979-1638
URLs: http://www.rite-group.com/rich
http://www.myonlinehomeinventory.com
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
[osol-discuss] Re: apt-get functionality (Was joining Sun)
On Wed, 2007-03-21 at 12:22 -0500, Eric Boutilier wrote: On Wed, 21 Mar 2007, Erast Benson wrote: On Wed, 2007-03-21 at 08:18 -0500, Eric Boutilier wrote: But that just brings us back to Joe's original point: Isn't that Nexenta? Note the Nexenta project is by all rights and intentions (Erast, correct me if I'm wrong) a project of and by the OpenSolaris community. Yes, its entierly driven by the Community developers and users who generates bug reports... We just trying to coordinate the effort and sometimes(when time permits) contribute to the project. Money-wise, it relies on Users donatations and Google adverts. So, if you do not donated yet, please do.. :-) Periodic donations especially appreciated. We also need more build x86 machines to deploy. There are many areas which needs to be improved. ON/NWS better integration is just one of them. We also would like to move GNU/Debian userland to Feisty branch, but this will require 2 engineers 1 month full time, so the hope is that involved Companies(those who trying to use NexentaOS) will donate engineering force for us.. Would it help cost-wise to consider migrating some things? I would think at least some of your apps/DB/mail systems could use the HW/SW infrastructure and bandwidth that opensoloaris.org provides... We are pretty happy with hosting provided by Stanford University, but I think some projects could be moved to opensolaris.org, like apt-get/dpkg ports, debhelper, hackzone tools, fileutils, etc, as subprojects of some top-level consolidation - GNU/OpenSolaris (i.e. not Solaris), so it will create dedicated mailing lists for those small projects. Eric (Question for the future OGB: does a Project/Community have to be hosted on opensolaris.org in order to qualify its members for Core Contributor status?) -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
Stefan Teleman wrote: 2. The currently proposed Apache 2.2.4 integration installs Apache in /usr/apache2, thereby _overwriting_ the existing Apache 2.0.x. Having recently gone down the path of installing/upgrading Apache on OS-b56, the current scheme is confusing at best. With 2 versions delivered by Sun, another two by Blastwave, and a 3rd set via the Apache source INSTALL/README notes, this whole area is difficult to navigate. Especially if you need a configuration or modules that differ from the one(s) pre-built and delivered on your system. Creating yet another install, with its own svc manifest names, its own config files, its own modules, etc... just makes the above picture worse. As much as I would like to be able to run both old and new side-by-side, it isn't worth the additional admin complexity that it entails. Please don't go there. -John ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
[responding to my own post - sorry] John Plocher wrote: Stefan Teleman wrote: 2. The currently proposed Apache 2.2.4 integration installs Apache in /usr/apache2, thereby _overwriting_ the existing Apache 2.0.x. As much as I would like to be able to run both old and new side-by-side, it isn't worth the additional admin complexity that it entails. Please don't go there. I should have been clearer - I like this overwrite proposal (as opposed to a the counter of having /usr/apache, /usr/apache2 and /usr/apache2.2), as long as the svc manifest names are the same as used by the current apache2 installation (svc:/network/http:apache) and not, for example, svc:/network/http:apache2.2. -John ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
John Plocher wrote: I should have been clearer - I like this overwrite proposal (as opposed to a the counter of having /usr/apache, /usr/apache2 and /usr/apache2.2), as long as the svc manifest names are the same as used by the current apache2 installation (svc:/network/http:apache) and not, for example, svc:/network/http:apache2.2. Yes, the svc manifest names will be preserved. --Stefan -- Stefan Teleman Sun Microsystems, Inc. [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [sfwnv-discuss] Re: [osol-discuss] Web Stack NG Project: Questions for the Community
These ARC cases are for integration to Solaris, so /opt is inappropriate, and /usr is correct. Oh in that case, I agree. *Provided* that the CoolStack stuff will replace the current stuff on the Solaris distribution media. Just for clarification, the integration that Stefan is working on isn't of CoolStack per-se. He has worked closely with that particular team to gather requirements and optimizations but this project is a separate effort to integrate a subset of web tier components into OpenSolaris along with many of their underlying dependencies. After the initial phase of the project has been completed, the intent is to integrate additional web tier components (and their various dependencies). dsc ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Web Stack NG Project: Questions for the Community
The ARC Cases for the WebStack NG Project have been submitted for review (and hopefully approval), and i would like to ask our community's input regarding two important questions which have come up during our discussions: 1. Should the initial components released for this project include the 64-bit bits in the initial Integration ? I would think so. Does anyone have benchmarks of a 64-bit compiled WebStack vs 32-bit equivilents? 2. The currently proposed Apache 2.2.4 integration installs Apache in /usr/apache2, thereby _overwriting_ the existing Apache 2.0.x. Valid arguments have been made pro, and against this approach, with the suggestion that Apache 2.2.4 installs in /usr/apache2.2, thereby preserving the existing /usr/apache2. However, this alternate location would *not* alter the EOF/EOL timeout announced for Apache 2.0.x. I can't imagine anyone who has spent time in the *real* world would suggest that the apache 2.2.4 replace the existing apache 2.0.x. They would understand that in many cases, the consumer would like to be able to baseline their existing apache 2.0.x install vs a new install which may behave differently than they expect. Having to *reload* Apache 2.0.x because Apache 2.2.4 didn't work as expected is an undue burden, and makes it difficult to do a side by side test. In the case of *replacing* apache 2.0.x, a user would require *2* systems to baseline, instead of one. What's wrong with letting the consumer *decide* when to remove an obsoleted version of apache? This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: Web Stack NG Project: Questions for the Community
Correct. Existing configuration files will *not* be overwritten. How do you propose handling Apache modules? The module API changed between 2.0 and 2.2, and it is not possible to load 2.0 modules under 2.2 . Cheers Andrew. This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] marTux boots on T2000 - Cosmic thanks and regards to Menno Lageman !!
Martin Bochnig wrote: ### ### ## ## Cosmic thanks and regards to Menno Lageman !! ## ### ### Menno Lageman - Sun Microsystems - http://blogs.sun.com/menno has gently invested his weekend and has tested marTux_0.2 on sun4v for us, enjoy: There are are few (easily solvable [wait for marTux_0.3 due until April30th]) issues, but it already boots up: ... Hi Martin, this is excellent news. I just wish that I had a T2000 to play with so I could explore MarTux in style. Makes me wonder, though - has anybody tried booting MarTux on a StarCat (F15K/25K) or StarKitty (F12K/20K) ? cheers, James C. McPherson -- Solaris kernel software engineer, system admin and troubleshooter http://www.jmcp.homeunix.com/blog Find me on LinkedIn @ http://www.linkedin.com/in/jamescmcpherson ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: blastwave package handling
Octave Orgeron wrote: What if we do something like this: [details ellided] At the risk of repeating myself for about the 50th time in the past year, I'd encourage these packaging-related discussions to occur with the community list specifically devoted to them, [EMAIL PROTECTED] Those in the community with ideas can actually start working on them, since the packaging sources are open, and have been for over a year now. Dave ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
On Wednesday 21 March 2007 09:28 am, Stefan Teleman wrote: 2. The currently proposed Apache 2.2.4 integration installs Apache in /usr/apache2, thereby _overwriting_ the existing Apache 2.0.x. Valid arguments have been made pro, and against this approach, with the suggestion that Apache 2.2.4 installs in /usr/apache2.2, thereby preserving the existing /usr/apache2. However, this alternate location would *not* alter the EOF/EOL timeout announced for Apache 2.0.x. Stefan, Your suggestion above might be the best. The other thing is, what about having 2 seperate directories, keeping the old and adding the new, and using a symlink to point to the desired version. -- Alan DuBoff - Solaris x86 Engineering - IHV/OEM Group Advocate of insourcing at Sun - hire people that care about our company! ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: joining Sun
On Wednesday 21 March 2007 05:59 am, Simon Phipps wrote: Now, y'all boys realize what this leads to. Simon joining MSFT. Don't make me say it! Wait, I just said it... Owh. They stopped calling a year or so ago... That does give you some credence, they stopped calling me close to 20 years ago...:-/ -- Alan DuBoff - Solaris x86 Engineering - IHV/OEM Group Advocate of insourcing at Sun - hire people that care about our company! ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: blastwave package handling
Eric Boutilier wrote: At the risk of repeating myself for about the 50th time in the past year, I'd encourage these packaging-related discussions to occur with the community list specifically devoted to them, [EMAIL PROTECTED] Those in the community with ideas can actually start working on them, since the packaging sources are open, and have been for over a year now. An interesting metric would be the percentage of core contributors who (understandably IMO) don't read this list. Eric, you're one of the few who could actually produce that result ;-) I know I can't. What I can say is that I do read every message that comes to install-discuss, while I only read a portion of opensolaris-discuss, so the metric you suggest still doesn't accurately reflect the actual chances of gaining attention of those you might wish to engage... Hey, if it would help get people directed in the right place I'd split off a packaging-discuss list for the SVR4 packaging project, but I tend to doubt it would have any real effect, since these conversations (as was the case here) all too often are a digression from some completely different initial topic. But I'd certainly take feedback on that idea. Dave ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
Alan DuBoff wrote: Stefan, Your suggestion above might be the best. The other thing is, what about having 2 seperate directories, keeping the old and adding the new, and using a symlink to point to the desired version. This was one of the other suggestions made on the ARC discuss list. My primary concern about keeping both 2.0.x and 2.2.4 around (albeit temporarily) is that it creates the possibility of a huge disaster: application X links againsr /uar/apache2 application Y links against /usr/apache2.2 application Z links against X and Y If this were ever to happen, it would be discovered quite quickly (i'm willing to bet that any apache module linked in such a dysfunctional fashion will crash very quickly). The question then becomes: in the interest of preserving Sun customers' existing installations, easing the transision pain, and giving enough leeway for module porting and regression testing, is the possibility described above an acceptable risk ? --Stefan -- Stefan Teleman Sun Microsystems, Inc. [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
On 3/19/07, Dale Ghent [EMAIL PROTECTED] wrote: On Mar 19, 2007, at 11:53 AM, Ian Murdock wrote: Hi all, Hi, Ian, welcome to the community! Thanks! (SOrry for the delay weighing in--it's been a bit hectic these past few days..) You laid out a general outline of what you'll be doing at Sun, however as a matter of curiosity, I'm wondering what really compelled you to take this position at Sun given that your background is decidedly light-weight vis-à-vis Solaris. In your blog entry, you talk about hoping to impart more usability in Solaris, but that is a broad subject and can mean anything (or everything, as the case might be.) I'm confused by the continued balancing act Sun is playing regarding its stance towards Linux in relation to its own Solaris product. For example, IBM make comparatively more sense regarding its positioning of Linux and its own AIX - Linux being defined as IBM's small/ commodity platform OS and AIX having a defined role on IBM's mid-to- high end POWER-based platforms which are not commodity. There's a decently defined role for each. Sun and Solaris are different, though, where Solaris is at home at virtually all price points. This is where my confusion lays. Why is Sun still trying to play the Linux benefactor role (outside of certifying its hardware for, eg: RHEL and the like) when Solaris has become able to play consistently from the low-end fields all the way up to the top? I'm not trying to be combative... just genuinely curious. Good luck settling in to your new digs! Great questions. As I said in my blog, I cut my teeth first on SunOS, then Solaris, so while I haven't done much with Solaris *recently*, I do have some history here. I'm here because I think very highly of Sun, and because I enjoy a good challenge too. In addition, Sun is in a great position. If you ask me, Solaris has outinnovated Linux in the last few years (with DTrace, ZFS, ...) and also has a great story around more mundane but critical things like backward compatibility, an area where Linux is notably very weak. When I say I'm hoping to help close the usability gap, I'm primarily talking about improving the things that make Solaris look like it's technologically where Linux was 10 years ago, which of course isn't true at all, but many potential users will never get past When I hit backspace, I get ^H--Linux hasn't done that since 1995! There are some interesting connections to Linux here as well. If you think about it, what do people want when they say they want Linux? The Linux kernel? Or the Linux distribution (i.e., GNU)? Could Solaris become a better Linux than Linux by following that line of thinking? And if you following that line of thinking, where does that lead the company in terms of Linux strategy? Some interesting parallels open up with the way Sun masterfully embraced x86 a few years ago... Anyway, as you can probably tell, I don't arrive with any shortage of ideas--indeed, I've developed a lot of these ideas in full view on my blog over the past few years. However, as I said before, I'm planning to spend the next few months learning as much as I can and listening to as many people as possible. I AM a newcomer here, which means I come with fresh ideas and a lot of experience (both in what to do and what not to do), but which also means I need to earn my voice. Let the earning begin! :-) -ian -- Ian Murdock 650-331-9324 http://ianmurdock.com/ Don't look back--something might be gaining on you. --Satchel Paige ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
great stuff snipped I AM a newcomer here, which means I come with fresh ideas and a lot of experience (both in what to do and what not to do), but which also means I need to earn my voice. Let the earning begin! You're the real honest to goodness community type person that we need around here and not a corporate convert that someone is trying to sell the idea of community to. You already have 99% of the hard stuff covered on day one. Its just really great to see someone who is an officer position in Sun actually know how to talk to the community and how to interact. Something we never see around here unless a catttle prod is used. Really .. its so great to see Mr. Debian here. :-) Dennis Clarke [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: Re: Fluendo announces multimedia for Linux and
On Wed, 7 Feb 2007, Brian Cameron wrote: Richard: I think gaim 2.0beta_whatever (maybe from blastwave) uses GStreamer, but I never got it to work (although ISTR some email archives in which that was a known problem not fully resolved). I ended up using NAS (can't remember where I got that) and the associated auplay command, since that had less latency than audioplay (and no start/end pops), and less pauses and such than whatever JDS/GNOME would prefer one used as an audio server (esd?). GStreamer seems to slowly becoming the standard for audio/video in the GNOME desktop. The esd (Enlightened Sound Daemon) project is pretty dead at the moment (and currently maintained by a GStreamer developer, by the way). Remember that NAS, JACK, ALSA, and other popular audio frameworks are Linux specific and would require significant porting effort to get working in Solaris. Ahh! :) I am the NAS maintainer - I try very hard to ensure that nas is not linux specific. And it isn't. NAS works fine in solaris, last I heard. GStreamer can use NAS as a backend as well. I know this is an old thread, I haven't checked it in a few months as you can see :( But is NAS does not run on Solaris, I'd certainly like to know about it. -- Jon Trulson mailto:[EMAIL PROTECTED] #include std/disclaimer.h No Kill I -Horta ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: joining Sun
On Mar 21, 2007, at 04:46, Artem Kachitchkine wrote: Alan DuBoff wrote: On Tuesday 20 March 2007 02:59 pm, Nicolas Linkert wrote: That's really good news. The next big bang may be: Jörg Schilling is joining Debian. Everything seems possible ;) Ah, now it's all making sense...I did note he had some good things to say about Debian in his OGB podcast, maybe Joerg was preparing us for the news that he is joining Debian...LOL! Now, y'all boys realize what this leads to. Simon joining MSFT. Don't make me say it! Wait, I just said it... Owh. They stopped calling a year or so ago... These days Google is calling everybody. You're not in the in crowd unless you have had the telephone slammed down on you by some giggling Google guy. :-) Dennis ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
On Wed, 2007-03-21 at 16:38 -0400, Dennis Clarke wrote: Really .. its so great to see Mr. Debian here. :-) +1 :-) -- Erast ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
Alan DuBoff writes: The other thing is, what about having 2 seperate directories, keeping the old and adding the new, and using a symlink to point to the desired version. That's what we do with Java, and it's not nice with sparse zones. I'd expect Apache to be used commonly with zones, so I'd recommend against this. -- James Carlson, Solaris Networking [EMAIL PROTECTED] Sun Microsystems / 1 Network Drive 71.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
[osol-discuss] Re: blastwave package handling [was Re: Re: joining Sun]
Jason Ozolins writes: Blastwave package upgrade == package remove followed by package install. Not like, say, RPM's handing of upgrades at all. The service stops while the upgrade happens. Not to mention, some of our config files got creamed (this is really the packager's problem rather than inherent in SVR4 packages). This kind of explains why Sun puts out _patches_ rather than new versions of packages - because applying the latter can't be done easily to a running OS instance. SVR4 package management just wasn't designed to work the way that people expect package management to work these days. Not true on both counts. What are the two counts? My supposed misunderstanding of patches vs packages is one, but I'm not sure which of my other statements is supposed to be bogus. A Solaris upgrade (as opposed to patches) uses packages. The difference is that the upgrade process uses SVr4 'admin' files when necessary. Blastwave could do this with instance=overwrite, and probably should, but it doesn't. Umm, I think we're writing at cross purposes here... you don't do a Solaris _upgrade_ to a running OS instance. Live upgrade, or boot from install media and upgrade, but in either cases, you aren't running services from the OS instance that is being upgraded, which is the case I'm interested in. If I want to (topical example) upgrade the Solaris telnet daemon on a running system, I'll be installing a _patch_, not performing a package upgrade. But if for the sake of discussion it was Blastwave's telnetd, the only way to upgrade it on a running OS instance would be to perform a _package upgrade_. Remove package, shared libs, kill daemon for duration of upgrade, [probably killing running telnet sessions in the process] reinstall package, maybe cream config files somewhere in the process. I understand and sympathise with the Blastwave packaging decisions (see D. Clarke's later posting on patches having their own dependencies), but I think they reflect problems with the SVR4 packaging setup. We moved off Blastwave openldap and apache because when we did a pkg-get upgrade to get some security fixes, it: - creamed our server SSL certs - broke our apache PubCookie module that was built against the apache libs and openldap libs - started a bunch of daemons from Blastwave packages, even though the daemons' rc3.d scripts were disabled and so the townsfolk were heard to say this is crazy, either we host this service on CentOS 4, where this kind of chaos hasn't happened to us, or build our own packages for Solaris (whee). Makes it a bit hard for the resident Solaris fan (me, SunOS user since 1988, admin since 1992) to put forward that we should be hosting _more_ services on Solaris. I'll take the advice of Dave Miner and go get flamed over at the packaging community now. When I get some free time I will also do what Martin Bochnig suggested and try to help out rather than complain. But my original post was just trying to point out that the existence of Blastwave and Sunfreeware is not enough for Solaris to win mindshare among folks who have used Linux distros with decent package management, an example being my co-workers and management. If I failed to understand some nuanced differences between Solaris patches and packages, it really doesn't detract from that point. -Jason Ozolins ANU Supercomputer Facility This message posted from opensolaris.org ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] marTux boots on T2000 - Cosmic thanks and regards to Menno Lageman !!
James C. McPherson wrote: Hi Martin, this is excellent news. I just wish that I had a T2000 to play with so I could explore MarTux in style. Makes me wonder, though - has anybody tried booting MarTux on a StarCat (F15K/25K) or StarKitty (F12K/20K) ? cheers, James C. McPherson -- Solaris kernel software engineer, system admin and troubleshooter http://www.jmcp.homeunix.com/blog Find me on LinkedIn @ http://www.linkedin.com/in/jamescmcpherson Hi, good morning, marTux_0.2 for sparc was pre-mature. Please don't use it. Especially its SMF had been sick. Please don't try it out, before marTux_0.2 for sparc is released (April 30th). Regards, Martin ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] marTux boots on T2000 - Cosmic thanks and regards to Menno Lageman !!
Martin Bochnig wrote: Hi, good morning, marTux_0.2 for sparc was pre-mature. Please don't use it. Especially its SMF had been sick. Please don't try it out, before marTux_0.2 for sparc is released (April 30th). err, _0.*3* Regards, Martin ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] Re: blastwave package handling
On Wed, 21 Mar 2007, Dave Miner wrote: ... Hey, if it would help get people directed in the right place I'd split off a packaging-discuss list for the SVR4 packaging project, but I tend to doubt it would have any real effect, since these conversations (as was the case here) all too often are a digression from some completely different initial topic. But I'd certainly take feedback on that idea. I agree that it might not have much effect. I guess what I'd like to see is an increase in signposts. Which is to say, people posting one-liners pointing out when a list/audience exists that is specifically dedicated to a topic being discussed here. Eric ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: blastwave package handling [was Re: Re: joining Sun]
Jason Ozolins wrote: Umm, I think we're writing at cross purposes here... you don't do a Solaris _upgrade_ to a running OS instance. Live upgrade,...but in either cases, you aren't running services from the OS instance that is being upgraded, which is the case I'm interested in. If I want to (topical example) upgrade the Solaris telnet daemon on a running system, I'll be installing a _patch_, not performing a package upgrade. Patches are (under the covers) simply collections of sparse packages; most of which require you to be running in single user mode so that all those running processes are in fact explicitly /not/ running. When you install the telnet patch, patchadd simply[1] uses pkgadd to do an overwrite-install of the package containing a new telnetd binary[2]. If you do this on a system running multi-user, and are lucky, telnetd will drop a core when the paging system can't find the backing store for the original executable. If you are unlucky, you will *think* you have fixed the security hole, but the daemon actually running on your system will still be wide open - at least until you manually restart the daemon. -John [1] for some tortured definition of the word simply. [2] from man patchadd: NOTES ... pkgadd is invoked by patchadd and executes the installation scripts in the pkg/install directory. ... Contents of log file for a successfull installa- tion: patchadd redirects pkgadd's output to the patch ins- tallation log file. For a successfull installation, pkgadd will produce the following message that gets inserted into the log file: This appears to be an attempt to install the same architecture and version of a package which is already installed. This installation will attempt to overwrite this package. This message does not indicate a failure, it represents the correct behavior by pkgadd when a patch installs correctly. ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: blastwave package handling [was Re: Re: joining Sun]
snippage Jason, it would have been helpful if you had just simply contacted me. I'm generally real real busy but I take things like this quite seriously and so do the team of guys that work on these sort of packages. The list of people involved in Apache and OpenSSL etc at Blastwave is stellar I assure you. Serious engineers from Sun, Pixar, Stanford, Penn State etc. We work real hard. I know that we are often up night after night working an issue or a fix or a tweak to make sure that it does actually work. So posting all your problems here is sort of okay, I guess, and I can not fault you for being frustrated. That is my fault. Not yours. The mail list for users is at [EMAIL PROTECTED] and we would love to hear from you there. Tonight and last night and maybe even tomorrow I am sweating out the last details of our GNOME release. That has me ties up but the Apache guys would love to hear from you. Dennis Clarke [EMAIL PROTECTED] ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Re: blastwave package handling
n.b.: I think we need a new subject header.
Jason Ozolins wrote:
Umm, I think we're writing at cross purposes here... you don't do a
Solaris _upgrade_ to a running OS instance. Live upgrade,...but in
either cases, you aren't running services from the OS instance that
is being upgraded, which is the case I'm interested in. If I want
to (topical example) upgrade the Solaris telnet daemon on a running
system, I'll be installing a _patch_, not performing a package upgrade.
Patches are (under the covers) simply collections of sparse
packages; most of which require you to be running in single
user mode so that all those running processes are in fact
explicitly /not/ running.
WARNING : Herein Lies Preaching to the Choir
It is generally a really good idea to be in single user mode or at
least in a really quiet state. I have patched systems in full multi-user
mode ( init 3 ) but only after I toss out all users, lock them out to
keep them out, and shut down all network daemons, drop NFS mounts, kill
the power daemon as well as anything else remotely questionable. After
all of that I still get a very successful patch process as well as a
kernel update *BUT* you do need to touch /reconfigure and then reboot.
I do that under duress and only when there is no way to get access to
the console. Thankfully LOM makes that a silly old thing. Even four and
five year old PC gear can have the console redirected to TTYA.
In any case, what I am saying here is that you take your own server
stability into your own hands if you do not drop down to single user mode.
When you install the telnet patch, patchadd simply[1] uses
pkgadd to do an overwrite-install of the package containing
a new telnetd binary[2].
cool .. I have no problem with that.
If you do this on a system running multi-user, and are lucky,
don't do that. see above .
telnetd will drop a core when the paging system can't find
the backing store for the original executable. If you are
unlucky, you will *think* you have fixed the security hole,
but the daemon actually running on your system will still be
wide open - at least until you manually restart the daemon.
drop to single user mode .. get on the console .. patch, reboot, smile
works for me and I blog about stuff like this too :
http://www.blastwave.org/dclarke/blog/?q=node/47
Dennis Clarke
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Re: [osol-discuss] Web Stack NG Project: Questions for the Community
On Wednesday 21 March 2007 01:23 pm, Stefan Teleman wrote: This was one of the other suggestions made on the ARC discuss list. My primary concern about keeping both 2.0.x and 2.2.4 around (albeit temporarily) is that it creates the possibility of a huge disaster: application X links againsr /uar/apache2 application Y links against /usr/apache2.2 application Z links against X and Y What about a scenario like this: /usr/apache2.0.x /usr/apache2.2.x /usr/apache2 - apache2.0.x /usr/apache2.0.x - compiled with respective /usr/apache2.0.x runpath(s) /usr/apache2.2.x - compiled with respective /usr/apache2.2.x runpath(s) Simply put, the binaries would be compiled with the physical runpath, opposed to the symlink. The user could easily change the apache2 symlink if it bothers them, and that would point to the new version, but would allow your entire stack to use the runpath you compiler for. The user has what they have today, /usr/apache2 which points to the respective path which represents the version installed today. Your code could and will use the new /usr/apache2.2.x runpath, so that it resolves properly. The user still has the option of manually changing the symlink to point to the newer version, and would save themself having to modify their build environment, if that's worth something to them. If this were ever to happen, it would be discovered quite quickly (i'm willing to bet that any apache module linked in such a dysfunctional fashion will crash very quickly). Doctor, my programs crash when I compile with /usr/apache2.0.x and /usr/apache2.2.x, what do you reccomend to fix that?:-/ The user could still use the new code by compiling with runpath to the hard path, without changing much at all. Maybe I'm missing something, it seems to make sense to me. -- Alan DuBoff - Solaris x86 Engineering - IHV/OEM Group Advocate of insourcing at Sun - hire people that care about our company! ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
Re: [osol-discuss] joining Sun
On Wednesday 21 March 2007 02:32 pm, Erast Benson wrote: On Wed, 2007-03-21 at 16:38 -0400, Dennis Clarke wrote: Really .. its so great to see Mr. Debian here. :-) +1 :-) Thanks Dennis, you have seconds. I'll contact you offline to setup your Debian fan club community.:-/ Seriously, I hope to see Ian active with the OpenSolaris community.;-) -- Alan DuBoff - Solaris x86 Engineering - IHV/OEM Group Advocate of insourcing at Sun - hire people that care about our company! ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
[osol-discuss] [SVOSUG] Network Auto-Magic - Tonight! Mar. 22nd, 7:30pm - SCA03
*** REMINDER *** REMINDER *** REMINDER *** REMINDER *** SVOSUG has what I consider a special meeting this month. John Beck will be giving a presentation on his OpenSolaris project, Network Auto-Magic. You can read about this project on the OpenSolaris webpage at: http://www.opensolaris.org/os/project/nwam/ The reason this is such a special meeting to me is that Solaris/OpenSolaris has been known for being a server product, and user applications have not been a primary focus. The Network Auto-Magic is to automate network configuration, something that is of need for mobile computers. This project does represent a milestone event for OpenSolaris! It seems Sun dropped support for laptops in Solaris 8 on x86, the latest builds of Solaris/OpenSolaris do in fact run much better on laptops, and a lot of work has gone into the code to help out. The Network Auto-Magic project really does represent the evolution of Solaris/OpenSolaris as we are seeing it change and werever it will go. This should prove to be a very interesting talk, please feel free to call-in if you're not in the area. I'm told the polycoms will be setup around the room. This will allow for a more interactive environment for the folks that call-in. For those in need of something special, John likes plain MMs! When: Thursday, Mar. 22nd, 2007 Where: Sun's Santa Clara Campus Auditorium (SCA03 upstairs) What: Network Auto-Magic Time: 7:30pm-10:00pm Map: http://blogs.sun.com/roller/resources/aland/scasj_dirmap.pdf Call-in Info: Toll Free: 866-545-5227 Intnl/pay: 865-673-6950 Conference: 809-64-14 -- Alan DuBoff - Solaris x86 Engineering - IHV/OEM Group Advocate of insourcing at Sun - hire people that care about our company! --- -- Alan DuBoff - Solaris x86 Engineering - IHV/OEM Group Advocate of insourcing at Sun - hire people that care about our company! ___ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
