|
Replies:
143
-
Last Post:
Apr 11, 2007 2:55 AM
by: udippel
|
|
|
Posts:
50
From:
Registered:
3/17/07
|
|
|
|
joining Sun
Posted:
Mar 19, 2007 8:53 AM
|
|
Hi all,
It's being announced today that I'm joining Sun as chief operating
platforms officer, which basically means I'll be in charge of Sun's
operating system strategy, spanning Solaris and Linux. I just posted the
announcement on my blog (http://ianmurdock.com/2007/03/19/joining-sun/),
and it'll likely be making the rounds soon. Just wanted to
make sure you heard the news directly from me and to introduce myself.
First things first: I'm a long time Linux user, developer, and advocate.
I founded Debian in 1993, co-founded a Linux distribution company called
Progeny in 1999, and most recently served as CTO of the new Linux
Foundation, where I was (and still am) chair of the LSB, the Linux
platform interoperability standard. I'm also a long time Sun fan.
As for what I'll be doing: While I'm coming in with some fairly formed
opinions about what Sun/Solaris/OpenSolaris ought to do (peruse my
blog a bit to learn more), I'm also a big believer in listening
before talking, and I have a lot of listening to do in the weeks
to come. So, please, feel free to drop me a line if you have
anything to tell me. And, please, be gentle while I get settled. :-)
Gotta get on a call in a few minutes. In the meantime, I just wanted
to say hello, and to make sure you heard the news directly from me.
Later,
-ian
--
Ian Murdock
http://ianmurdock.com/
"Don't look back--something might be gaining on you." --Satchel Paige
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
Jason J. W. Wil...
jasonjwwilliams@gmai...
|
|
|
|
Re: joining Sun
Posted:
Mar 19, 2007 9:42 AM
in response to: imurdock
|
|
Hi Ian,
That's terrific!
<3rd grade chanting>Packing's gonna get fixed...packaging's gonna get
fixed...!</chanting>
All kidding aside, you being on OpenSolaris is spectacular! **** near
causing a house party where I works.
Hope you have fun at it.
Best Regards
Jason
On 3/19/07, Ian Murdock <imurdock at imurdock dot com> wrote:
> Hi all,
>
> It's being announced today that I'm joining Sun as chief operating
> platforms officer, which basically means I'll be in charge of Sun's
> operating system strategy, spanning Solaris and Linux. I just posted the
> announcement on my blog (http://ianmurdock.com/2007/03/19/joining-sun/),
> and it'll likely be making the rounds soon. Just wanted to
> make sure you heard the news directly from me and to introduce myself.
>
> First things first: I'm a long time Linux user, developer, and advocate.
> I founded Debian in 1993, co-founded a Linux distribution company called
> Progeny in 1999, and most recently served as CTO of the new Linux
> Foundation, where I was (and still am) chair of the LSB, the Linux
> platform interoperability standard. I'm also a long time Sun fan.
>
> As for what I'll be doing: While I'm coming in with some fairly formed
> opinions about what Sun/Solaris/OpenSolaris ought to do (peruse my
> blog a bit to learn more), I'm also a big believer in listening
> before talking, and I have a lot of listening to do in the weeks
> to come. So, please, feel free to drop me a line if you have
> anything to tell me. And, please, be gentle while I get settled. :-)
>
> Gotta get on a call in a few minutes. In the meantime, I just wanted
> to say hello, and to make sure you heard the news directly from me.
>
> Later,
>
> -ian
> --
> Ian Murdock
> http://ianmurdock.com/
>
> "Don't look back--something might be gaining on you." --Satchel Paige
> _______________________________________________
> opensolaris-discuss mailing list
> opensolaris-discuss at opensolaris dot org
>
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
142
From:
Adelaide, South Australia
Registered:
9/11/06
|
|
|
|
Re: joining Sun
Posted:
Mar 19, 2007 4:59 PM
in response to: Jason J. W. Wil...
|
|
Jason,
> <3rd grade chanting>Packing's gonna get fixed...packaging's gonna get
> fixed...!</chanting>
Indeed, apt-get for Solaris would be quite useful :P
DSL
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Joe Little
jmlittle@gmail.com
|
|
|
|
Re: joining Sun
Posted:
Mar 19, 2007 5:08 PM
in response to: lloy0076
|
|
On 3/19/07, David Lloyd <lloy0076 at adam dot com dot au> wrote:
>
> Jason,
>
> > <3rd grade chanting>Packing's gonna get fixed...packaging's gonna get
> > fixed...!</chanting>
>
> Indeed, apt-get for Solaris would be quite useful :P
Isn't that Nexenta? Had to say it.
>
> DSL
> _______________________________________________
> opensolaris-discuss mailing list
> opensolaris-discuss at opensolaris dot org
>
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
142
From:
Adelaide, South Australia
Registered:
9/11/06
|
|
|
|
Re: joining Sun
Posted:
Mar 19, 2007 5:13 PM
in response to: Joe Little
|
|
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.
DSL
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,109
From:
Registered:
6/14/05
|
|
|
|
Re: joining Sun
Posted:
Mar 19, 2007 7:22 PM
in response to: lloy0076
|
|
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!", 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 at opensolaris dot org
|
|
|
|
|
Posts:
142
From:
Adelaide, South Australia
Registered:
9/11/06
|
|
|
|
Re: joining Sun
Posted:
Mar 20, 2007 3:29 PM
in response to: aland
|
|
Alan,
> 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!", 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.
That is what I meant.
It's possibly because I don't quite know how to use the "pkg*" commands
as well as "dpkg" that I don't like the actual packaging format.
> 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/
Thanks for the pointer.
DSL
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,695
From:
US
Registered:
4/28/05
|
|
|
|
apt-get functionality (Was joining Sun)
Posted:
Mar 21, 2007 6:18 AM
in response to: aland
|
|
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 at opensolaris dot org
>
>
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
278
From:
Registered:
5/12/06
|
|
|
|
Re: apt-get functionality (Was joining Sun)
Posted:
Mar 21, 2007 8:21 AM
in response to: ericb
|
|
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 at opensolaris dot org
> >
> >
> _______________________________________________
> opensolaris-discuss mailing list
> opensolaris-discuss at opensolaris dot org
>
--
Erast
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,695
From:
US
Registered:
4/28/05
|
|
|
|
Re: apt-get functionality (Was joining Sun)
Posted:
Mar 21, 2007 10:22 AM
in response to: erast
|
|
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 at opensolaris dot org
|
|
|
|
|
Posts:
278
From:
Registered:
5/12/06
|
|
|
|
Re: apt-get functionality (Was joining Sun)
Posted:
Mar 21, 2007 10:31 AM
in response to: ericb
|
|
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 at opensolaris dot org
|
|
|
|
|
Posts:
1,695
From:
US
Registered:
4/28/05
|
|
|
|
Re: apt-get functionality (Was joining Sun)
Posted:
Mar 21, 2007 10:52 AM
in response to: ericb
|
|
>
> 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...
Re-reading this, and based some of the darker days this this
list has seen, I now fear a reply like the following (not
from Erast though of course!)...
So I figured I'd just reply in advance. :)
> = Eric You Ignorant Pig, don't you get it! OBVIOUSLY, there are
> = some projects who highly value total independence.
> =
> = Yours,
> = Mountain Man[1]
Dear Mountain Man -- Sorry for the misunderstanding. I did
not intend to convey any personal sentiments about the value
of being independent, but rather about any resource issues
that the Nexenta project might be facing.
(IOW, I agree that total independence has great value.)
1. http://tinyurl.com/2ou9x3
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Jason J. W. Wil...
jasonjwwilliams@gmai...
|
|
|
|
Re: joining Sun
Posted:
Mar 30, 2007 6:39 PM
in response to: aland
|
|
Hi Alan,
A packaging system like apt is exactly what I'd like. Frankly, a
packaging system that blends the binary delivery benefits of apt plus
the source delivery benefits of "emerge" would be fantastic. The
network install is primarily what we're missing...that and the pkg
utilities just feel a little clunky in the 21st century. Sorry for the
extremely delayed response...been buried.
Best Regards,
Jason
On 3/19/07, Alan DuBoff <Alan dot DuBoff at sun dot com> 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!", 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 at opensolaris dot org
>
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Joerg Schilling
Joerg.Schilling@foku...
|
|
|
|
Re: joining Sun
Posted:
Mar 31, 2007 2:38 AM
in response to: Jason J. W. Wil...
|
|
"Jason J. W. Williams" <jasonjwwilliams at gmail dot com> wrote:
> Hi Alan,
>
> A packaging system like apt is exactly what I'd like. Frankly, a
> packaging system that blends the binary delivery benefits of apt plus
> the source delivery benefits of "emerge" would be fantastic. The
> network install is primarily what we're missing...that and the pkg
> utilities just feel a little clunky in the 21st century. Sorry for the
Feelings from the gut do not help in a discussion.
If you like to discuss this, please use technically based arguments.
BTW: has "pkgadd" already been enhanced to include a tsort(1) like
feature to automatically install a list of packages in the right order?
Jörg
--
EMail:joerg at schily dot isdn dot cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
js@cs.tu-berlin.de (uni)
schilling at fokus dot fraunhofer dot de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
pkgadd [was Re: joining Sun]
Posted:
Apr 2, 2007 5:45 AM
in response to: Joerg Schilling
|
|
Joerg Schilling writes:
> BTW: has "pkgadd" already been enhanced to include a tsort(1) like
> feature to automatically install a list of packages in the right order?
CRs 4159916 and 4795539.
(I think the latter should be closed as a dup of the former.)
--
James Carlson, Solaris Networking <james dot d dot carlson at sun dot com>
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 at opensolaris dot org
|
|
|
|
|
Jason J. W. Wil...
jasonjwwilliams@gmai...
|
|
|
|
Re: joining Sun
Posted:
Apr 2, 2007 9:08 AM
in response to: Joerg Schilling
|
|
Hi Joerg,
No need to get bristled about it. Feel is one of the big reasons folks
don't move off Linux...
-J
On 3/31/07, Joerg Schilling <Joerg dot Schilling at fokus dot fraunhofer dot de> wrote:
> "Jason J. W. Williams" <jasonjwwilliams at gmail dot com> wrote:
>
> > Hi Alan,
> >
> > A packaging system like apt is exactly what I'd like. Frankly, a
> > packaging system that blends the binary delivery benefits of apt plus
> > the source delivery benefits of "emerge" would be fantastic. The
> > network install is primarily what we're missing...that and the pkg
> > utilities just feel a little clunky in the 21st century. Sorry for the
>
> Feelings from the gut do not help in a discussion.
>
> If you like to discuss this, please use technically based arguments.
>
> BTW: has "pkgadd" already been enhanced to include a tsort(1) like
> feature to automatically install a list of packages in the right order?
>
> Jörg
>
> --
> EMail:joerg at schily dot isdn dot cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
> js@cs.tu-berlin.de (uni)
> schilling at fokus dot fraunhofer dot de (work) Blog: http://schily.blogspot.com/
> URL: http://cdrecord.berlios.de/old/private/ ftp://ftp.berlios.de/pub/schily
>
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,109
From:
Registered:
6/14/05
|
|
|
|
Re: joining Sun
Posted:
Apr 3, 2007 10:09 PM
in response to: Jason J. W. Wil...
|
|
On Friday 30 March 2007 06:39 pm, Jason J. W. Williams wrote:
> Hi Alan,
>
> A packaging system like apt is exactly what I'd like. Frankly, a
> packaging system that blends the binary delivery benefits of apt plus
> the source delivery benefits of "emerge" would be fantastic. The
> network install is primarily what we're missing...that and the pkg
> utilities just feel a little clunky in the 21st century. Sorry for the
> extremely delayed response...been buried.
>
> Best Regards,
> Jason
No problem with a late response, that's the good thing about the net, it gets
your mail when you're not there. That can also be a bad thing...:-/
Seriously, many people have talked about this in the past, and there are some
solutions today such as pkg-get which blastwave uses, and apt was ported with
Nexenta...but I don't think it would matter as long as people got their
packages and were able to have a network enabled install. I beleive we're
moving in that direction, and several projects are in progress that will
facilitate some of this, possibly with SysV packaging as Solaris uses today
(which would require changes of course).
Most all folks would like to see an automated dependency resolving packaging
system.
--
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 at opensolaris dot org
|
|
|
|
|
Jason J. W. Wil...
jasonjwwilliams@gmai...
|
|
|
|
Re: joining Sun
Posted:
Apr 4, 2007 5:06 PM
in response to: aland
|
|
Hi Alan,
> Seriously, many people have talked about this in the past, and there are some
> solutions today such as pkg-get which blastwave uses, and apt was ported with
> Nexenta...but I don't think it would matter as long as people got their
> packages and were able to have a network enabled install. I beleive we're
> moving in that direction, and several projects are in progress that will
> facilitate some of this, possibly with SysV packaging as Solaris uses today
> (which would require changes of course).
Actually I've used Nexenta and apt seems to work very nicely. In a lot
of ways Nexenta provides a nice middle ground for folks who like the
GNU userland and the Solaris kernel.
Also, I agree as long as network enabled install works that's really
what matters. It'd be nice if the packages were put in the official
paths instead of /opt/csw or /opt/sfw as on Linux systems...but my
understanding is that's the hope of the /usr/gnu project (to give
folks the option of which way to do it).
Best Regards,
Jason
>
> Most all folks would like to see an automated dependency resolving packaging
> system.
>
> --
>
> 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 at opensolaris dot org
|
|
|
|
|
Posts:
192
From:
Registered:
12/11/06
|
|
|
|
Re: joining Sun
Posted:
Apr 5, 2007 6:57 PM
in response to: aland
|
|
> Seriously, many people have talked about this in the
> past, and there are some
> solutions today such as pkg-get which blastwave
> uses, and apt was ported with
> Nexenta...but I don't think it would matter as long
> as people got their
> packages and were able to have a network enabled
> install. I beleive we're
> moving in that direction, and several projects are
> in progress that will
> facilitate some of this, possibly with SysV
> packaging as Solaris uses today
> (which would require changes of course).
>
It would nice to have more than just a network enabled
install possible. In nexenta, you can live upgrade to
the next release with apt.
Send instant messages to your online friends http://uk.messenger.yahoo.com
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,154
From:
US
Registered:
6/14/05
|
|
|
|
Re: joining Sun
Posted:
Apr 5, 2007 7:23 PM
in response to: freetown
|
|
On 05/04/07, Chung Hang Christopher Chan <chrisfz at yahoo dot com> wrote:
>
> > Seriously, many people have talked about this in the
> > past, and there are some
> > solutions today such as pkg-get which blastwave
> > uses, and apt was ported with
> > Nexenta...but I don't think it would matter as long
> > as people got their
> > packages and were able to have a network enabled
> > install. I beleive we're
> > moving in that direction, and several projects are
> > in progress that will
> > facilitate some of this, possibly with SysV
> > packaging as Solaris uses today
> > (which would require changes of course).
> >
>
> It would nice to have more than just a network enabled
> install possible. In nexenta, you can live upgrade to
> the next release with apt.
I've had many a "live upgrade" go awry over the years with Linux
distributions. I'd be more impressed with a reliable upgrade system,
even if it requires a reboot with media or special boot mode that is
faster than the current process. "live upgrade" in the "linux" context
strikes me as a "shiny" rather than "practical" thing in my personal
experience.
--
"Less is only more where more is no good." --Frank Lloyd Wright
Shawn Walker, Software and Systems Analyst
binarycrusader at gmail dot com - http://binarycrusader.blogspot.com/
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,091
From:
CA
Registered:
4/27/05
|
|
|
|
Re: joining Sun
Posted:
Mar 19, 2007 6:35 PM
in response to: lloy0076
|
|
On Tue, 20 Mar 2007, David Lloyd wrote:
> Indeed, apt-get for Solaris would be quite useful :P
Blastwave.org is thataway ----->
--
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 at opensolaris dot org
|
|
|
|
|
Posts:
29
From:
Registered:
6/14/05
|
|
|
|
Re: joining Sun
Posted:
Mar 20, 2007 4:33 PM
in response to: rich
To: OpenSolaris » discuss
|
|
> On Tue, 20 Mar 2007, David Lloyd wrote:
>
> > Indeed, apt-get for Solaris would be quite useful
> :P
>
> Blastwave.org is thataway ----->
Sad to say, but upgrading services (ldap, web, etc) running from Blastwave packages caused us a bunch of grief. We went back to building our own.
Doing a blanket upgrade to your Blastwave packages will (in our experience) start up daemons in BW packages even if you had previously disabled by removing /etc/rc3.d links.
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.
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
blastwave package handling [was Re: Re: joining Sun]
Posted:
Mar 21, 2007 5:35 AM
in response to: snorbert
|
|
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 <james dot d dot carlson at sun dot com>
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 at opensolaris dot org
|
|
|
|
|
Posts:
1,223
From:
India
Registered:
7/15/05
|
|
|
|
Re: blastwave package handling [was Re: Re: joining
Sun]
Posted:
Mar 21, 2007 6:09 AM
in response to: carlsonj
|
|
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 at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: blastwave package handling [was Re: Re: joining
Sun]
Posted:
Mar 21, 2007 6:22 AM
in response to: moinakg
|
|
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 <james dot d dot carlson at sun dot com>
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 at opensolaris dot org
|
|
|
|
|
Posts:
1,539
From:
Cobourg Ontario Canada
Registered:
4/27/05
|
|
|
|
Re: blastwave package handling [was Re: Re:
joining Sun]
Posted:
Mar 21, 2007 7:03 AM
in response to: carlsonj
|
|
>
> 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
dclarke at blastwave dot org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: blastwave package handling [was Re: Re: joining
Sun]
Posted:
Mar 21, 2007 7:11 AM
in response to: dclarke
|
|
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 <james dot d dot carlson at sun dot com>
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 at opensolaris dot org
|
|
|
|
|
Posts:
1,539
From:
Cobourg Ontario Canada
Registered:
4/27/05
|
|
|
|
Re: blastwave package handling
Posted:
Mar 21, 2007 7:18 AM
in response to: carlsonj
|
|
> 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 at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: blastwave package handling
Posted:
Mar 21, 2007 7:51 AM
in response to: dclarke
|
|
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 <james dot d dot carlson at sun dot com>
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 at opensolaris dot org
|
|
|
|
|
Posts:
976
From:
Винницкая область — область на западе Украины. (Vinnitsya, Ukraine)
Registered:
6/14/05
|
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: blastwave package handling
Posted:
Mar 21, 2007 8:21 AM
in response to: bochnig
|
|
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 <james dot d dot carlson at sun dot com>
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 at opensolaris dot org
|
|
|
|
|
Posts:
976
From:
Винницкая область — область на западе Украины. (Vinnitsya, Ukraine)
Registered:
6/14/05
|
|
|
|
|
|
Posts:
976
From:
Винницкая область — область на западе Украины. (Vinnitsya, Ukraine)
Registered:
6/14/05
|
|
|
|
Re: Re: blastwave package handling
Posted:
Mar 21, 2007 9:44 AM
in response to: bochnig
|
|
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 at opensolaris dot org
|
|
|
|
|
Posts:
1,539
From:
Cobourg Ontario Canada
Registered:
4/27/05
|
|
|
|
Re: Re: blastwave package handling
Posted:
Mar 21, 2007 9:08 AM
in response to: carlsonj
|
|
> 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 ?
Dennis
> 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.
<snippage>
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: blastwave package handling
Posted:
Mar 21, 2007 9:12 AM
in response to: dclarke
|
|
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 <james dot d dot carlson at sun dot com>
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 at opensolaris dot org
|
|
|
|
|
Posts:
513
From:
US
Registered:
6/14/05
|
|
|
|
Re: Re: blastwave package handling
Posted:
Mar 21, 2007 9:19 AM
in response to: carlsonj
|
|
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 <james dot d dot carlson at Sun dot COM> 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
> <james dot d dot carlson at sun dot com>
> 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 at opensolaris dot org
>
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Octave J. Orgeron
Solaris Systems Engineer
http://www.opensolaris.org/os/community/sysadmin/
http://unixconsole.blogspot.com
unixconsole at yahoo dot com
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
_____________________________________________________________________________ _______
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 at opensolaris dot org
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: blastwave package handling
Posted:
Mar 21, 2007 12:21 PM
in response to: oorgeron
|
|
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,
install-discuss at opensolaris dot org. 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 at opensolaris dot org
|
|
|
|
|
Posts:
1,695
From:
US
Registered:
4/28/05
|
|
|
|
Re: blastwave package handling
Posted:
Mar 21, 2007 12:41 PM
in response to: dminer
|
|
> 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, install-discuss at opensolaris dot org. 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
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: blastwave package handling
Posted:
Mar 21, 2007 1:06 PM
in response to: ericb
|
|
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, install-discuss at opensolaris dot org. 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 at opensolaris dot org
|
|
|
|
|
Posts:
1,695
From:
US
Registered:
4/28/05
|
|
|
|
Re: blastwave package handling
Posted:
Mar 21, 2007 6:39 PM
in response to: dminer
|
|
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 at opensolaris dot org
|
|
|
|
|
Posts:
1,695
From:
US
Registered:
4/28/05
|
|
|
|
Re: blastwave package handling
Posted:
Mar 22, 2007 7:52 AM
in response to: ericb
|
|
[Convention-aware me: "I'm sorry here for following up to my own post."
Actual Me: "Why should I be?"]
Previously, I wrote:
>Previously, Dave Miner 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,
>> install-discuss at opensolaris dot org. 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.
Sorry, major context error. What I meant to say was all opensolaris core
contributors (not just those of the install community).
Eric
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,674
From:
Registered:
7/15/05
|
|
|
|
Re: blastwave package handling [was Re: Re: joining
Sun]
Posted:
Mar 31, 2007 11:54 AM
in response to: moinakg
To: OpenSolaris » discuss
|
|
> 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.
This is something that sgi's `inst` excells at. It's a really ahead-of-its-time, elegant software management system that makes RPM, `apt-get` and especially system V packages look like toys in comparison.
Oh, and sgi built `inst` to understand System V packages. Installing the System V packaging eoe gives one `pkgadd` and friends... and they understand `inst` as well.
The only thing that comes close to `inst` is hp's `swinstall`. It's almost as intelligent and as elegant, just somewhat slower. HP did a very good job there, I have to say. Kudos to IRIX and HP-UX engineers.
|
|
|
|
|
Posts:
1,539
From:
Cobourg Ontario Canada
Registered:
4/27/05
|
|
|
|
Re: blastwave package handling [was Re: Re:
joining Sun]
Posted:
Mar 21, 2007 6:59 AM
in response to: carlsonj
|
|
> 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
dclarke at blastwave dot org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
976
From:
Винницкая область — область на западе Украины. (Vinnitsya, Ukraine)
Registered:
6/14/05
|
|
|
|
Re: blastwave package handling [was Re: Re: joining
Sun]
Posted:
Mar 21, 2007 7:03 AM
in response to: dclarke
|
|
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
>dclarke at blastwave dot org
>
>
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
martin at martux dot org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: blastwave package handling [was Re: Re: joining
Sun]
Posted:
Mar 21, 2007 7:12 AM
in response to: bochnig
|
|
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 <james dot d dot carlson at sun dot com>
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 at opensolaris dot org
|
|
|
|
|
Posts:
976
From:
Винницкая область — область на западе Украины. (Vinnitsya, Ukraine)
Registered:
6/14/05
|
|
|
|
Re: blastwave package handling [was Re: Re: joining
Sun]
Posted:
Mar 21, 2007 7:28 AM
in response to: carlsonj
|
|
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 0000,0000 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 0000,0000 rev 01 class 06,80,00
hdr 80
(II) PCI: 100:05:1: chip 108e,1101 card 0000,0000 rev 01 class 02,00,00
hdr 80
(II) PCI: 100:05:2: chip 108e,1102 card 0000,0000 rev 01 class 0c,00,10
hdr 80
(II) PCI: 100:05:3: chip 108e,1103 card 0000,0000 rev 01 class 0c,03,10
hdr 80
(II) PCI: 100:06:0: chip 1000,000f card 0000,0000 rev 37 class 01,00,00
hdr 80
(II) PCI: 100:06:1: chip 1000,000f card 0000,0000 rev 37 class 01,00,00
hdr 80
(II) PCI: 200:00:0: chip 108e,8001 card 0000,0000 rev 00 class 06,00,00
hdr 00
(II) PCI: 200:04:0: chip 1077,2200 card 0000,0000 rev 05 class 01,00,00
hdr 00
(II) PCI: End of PCI scan
(II) Host-to-PCI bridge:
(II) Bus 0@1: bridge is at (0@1:0:0), (0@1,0@1,0@2), BCTRL: 0x0008
(VGA_EN is set)
(II) Bus 0@1 I/O range:
[0] -1 1 0x00000000 - 0x00ffffff (0x1000000) IX[B]
(II) Bus 0@1 non-prefetchable memory range:
[0] -1 1 0x00000000 - 0xffffffff (0x0) MX[B]
(II) Bus 0@1 prefetchable memory range:
[0] -1 1 0x00000000 - 0xffffffff (0x0) MX[B]
(II) Host-to-PCI bridge:
(II) Bus 0@2: bridge is at (0@2:0:0), (0@2,0@2,0@2), BCTRL: 0x0008
(VGA_EN is set)
(II) Bus 0@2 I/O range:
[0] -1 2 0x00000000 - 0x00ffffff (0x1000000) IX[B]
(II) Bus 0@2 non-prefetchable memory range:
[0] -1 2 0x00000000 - 0xffffffff (0x0) MX[B]
(II) Bus 0@2 prefetchable memory range:
[0] -1 2 0x00000000 - 0xffffffff (0x0) MX[B]
(--) SBUS: (0xf0088588) Sun FFB2+ Vertical Creator 3D at
/upa@40,4480000/SUNW,ffb@0,0
(--) SBUS: (0xf008f754) Sun FFB2+ Vertical Creator 3D at
/upa@40,4480000/SUNW,ffb@1,0
(II) Addressable bus resource ranges are
[0] -1 2 0x00000000 - 0xffffffff (0x0) MX[B]
[1] -1 1 0x00000000 - 0xffffffff (0x0) MX[B]
[2] -1 2 0x00000000 - 0x00ffffff (0x1000000) IX[B]
[3] -1 1 0x00000000 - 0x00ffffff (0x1000000) IX[B]
(II) OS-reported resource ranges:
[0] -1 2 0xffffffff - 0xffffffff (0x1) MX[B]
[1] -1 2 0x000f0000 - 0x000fffff (0x10000) MX[B]
[2] -1 2 0x000c0000 - 0x000effff (0x30000) MX[B]
[3] -1 2 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[4] -1 1 0xffffffff - 0xffffffff (0x1) MX[B]
[5] -1 1 0x000f0000 - 0x000fffff (0x10000) MX[B]
[6] -1 1 0x000c0000 - 0x000effff (0x30000) MX[B]
[7] -1 1 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[8] -1 2 0x00ffffff - 0x00ffffff (0x1) IX[B]
[9] -1 2 0x00000000 - 0x00000000 (0x1) IX[B]
[10] -1 1 0x00ffffff - 0x00ffffff (0x1) IX[B]
[11] -1 1 0x00000000 - 0x00000000 (0x1) IX[B]
(II) Active PCI resource ranges:
[0] -1 2 0x00100000 - 0x001fffff (0x100000) MX[B]E
[1] -1 1 0x0012a000 - 0x0012bfff (0x2000) MX[B]E
[2] -1 1 0x00128000 - 0x0012ffff (0x8000) MX[B]E
[3] -1 1 0x00126000 - 0x00127fff (0x2000) MX[B]E
[4] -1 1 0x00124000 - 0x00127fff (0x4000) MX[B]E
[5] -1 1 0x01000000 - 0x01ffffff (0x1000000) MX[B]E
[6] -1 1 0x00122000 - 0x00123fff (0x2000) MX[B]E
[7] -1 1 0x00120000 - 0x0013ffff (0x20000) MX[B]E
[8] -1 1 0x00100000 - 0x001fffff (0x100000) MX[B]E
[9] -1 1 0x7e000000 - 0x7fffffff (0x2000000) MX[B]E
[10] -1 1 0x7d000000 - 0x7dffffff (0x1000000) MX[B]E
[11] -1 1 0x00180000 - 0x001fffff (0x80000) MX[B]E
[12] -1 1 0x00132000 - 0x00133fff (0x2000) MX[B]E
[13] -1 1 0x00130000 - 0x0013ffff (0x10000) MX[B]E
[14] -1 1 0x0012e000 - 0x0012ffff (0x2000) MX[B]E
[15] -1 1 0x0012c000 - 0x0012ffff (0x4000) MX[B]E
[16] -1 2 0x00000300 - 0x000003ff (0x100) IX[B]E
[17] -1 1 0x00000300 - 0x000003ff (0x100) IX[B]E
[18] -1 1 0x00000500 - 0x000005ff (0x100) IX[B]E
(II) Inactive PCI resource ranges:
[0] -1 1 0x00000400 - 0x000004ff (0x100) IX[B]E
(II) PCI Memory resource overlap reduced 0x00128000 from 0x0012ffff to
0x00129fff
(II) PCI Memory resource overlap reduced 0x00124000 from 0x00127fff to
0x00125fff
(II) PCI Memory resource overlap reduced 0x00120000 from 0x0013ffff to
0x00121fff
(II) PCI Memory resource overlap reduced 0x00100000 from 0x001fffff to
0x0011ffff
(II) PCI Memory resource overlap reduced 0x00130000 from 0x0013ffff to
0x00131fff
(II) PCI Memory resource overlap reduced 0x0012c000 from 0x0012ffff to
0x0012dfff
(II) Active PCI resource ranges after removing overlaps:
[0] -1 2 0x00100000 - 0x001fffff (0x100000) MX[B]E
[1] -1 1 0x0012a000 - 0x0012bfff (0x2000) MX[B]E
[2] -1 1 0x00128000 - 0x00129fff (0x2000) MX[B]E
[3] -1 1 0x00126000 - 0x00127fff (0x2000) MX[B]E
[4] -1 1 0x00124000 - 0x00125fff (0x2000) MX[B]E
[5] -1 1 0x01000000 - 0x01ffffff (0x1000000) MX[B]E
[6] -1 1 0x00122000 - 0x00123fff (0x2000) MX[B]E
[7] -1 1 0x00120000 - 0x00121fff (0x2000) MX[B]E
[8] -1 1 0x00100000 - 0x0011ffff (0x20000) MX[B]E
[9] -1 1 0x7e000000 - 0x7fffffff (0x2000000) MX[B]E
[10] -1 1 0x7d000000 - 0x7dffffff (0x1000000) MX[B]E
[11] -1 1 0x00180000 - 0x001fffff (0x80000) MX[B]E
[12] -1 1 0x00132000 - 0x00133fff (0x2000) MX[B]E
[13] -1 1 0x00130000 - 0x00131fff (0x2000) MX[B]E
[14] -1 1 0x0012e000 - 0x0012ffff (0x2000) MX[B]E
[15] -1 1 0x0012c000 - 0x0012dfff (0x2000) MX[B]E
[16] -1 2 0x00000300 - 0x000003ff (0x100) IX[B]E
[17] -1 1 0x00000300 - 0x000003ff (0x100) IX[B]E
[18] -1 1 0x00000500 - 0x000005ff (0x100) IX[B]E
(II) Inactive PCI resource ranges after removing overlaps:
[0] -1 1 0x00000400 - 0x000004ff (0x100) IX[B]E
(II) OS-reported resource ranges after removing overlaps with PCI:
[0] -1 2 0xffffffff - 0xffffffff (0x1) MX[B]
[1] -1 2 0x000f0000 - 0x000fffff (0x10000) MX[B]
[2] -1 2 0x000c0000 - 0x000effff (0x30000) MX[B]
[3] -1 2 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[4] -1 1 0xffffffff - 0xffffffff (0x1) MX[B]
[5] -1 1 0x000f0000 - 0x000fffff (0x10000) MX[B]
[6] -1 1 0x000c0000 - 0x000effff (0x30000) MX[B]
[7] -1 1 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[8] -1 2 0x00ffffff - 0x00ffffff (0x1) IX[B]
[9] -1 2 0x00000000 - 0x00000000 (0x1) IX[B]
[10] -1 1 0x00ffffff - 0x00ffffff (0x1) IX[B]
[11] -1 1 0x00000000 - 0x00000000 (0x1) IX[B]
(II) All system resource ranges:
[0] -1 2 0xffffffff - 0xffffffff (0x1) MX[B]
[1] -1 2 0x000f0000 - 0x000fffff (0x10000) MX[B]
[2] -1 2 0x000c0000 - 0x000effff (0x30000) MX[B]
[3] -1 2 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[4] -1 1 0xffffffff - 0xffffffff (0x1) MX[B]
[5] -1 1 0x000f0000 - 0x000fffff (0x10000) MX[B]
[6] -1 1 0x000c0000 - 0x000effff (0x30000) MX[B]
[7] -1 1 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[8] -1 2 0x00100000 - 0x001fffff (0x100000) MX[B]E
[9] -1 1 0x0012a000 - 0x0012bfff (0x2000) MX[B]E
[10] -1 1 0x00128000 - 0x00129fff (0x2000) MX[B]E
[11] -1 1 0x00126000 - 0x00127fff (0x2000) MX[B]E
[12] -1 1 0x00124000 - 0x00125fff (0x2000) MX[B]E
[13] -1 1 0x01000000 - 0x01ffffff (0x1000000) MX[B]E
[14] -1 1 0x00122000 - 0x00123fff (0x2000) MX[B]E
[15] -1 1 0x00120000 - 0x00121fff (0x2000) MX[B]E
[16] -1 1 0x00100000 - 0x0011ffff (0x20000) MX[B]E
[17] -1 1 0x7e000000 - 0x7fffffff (0x2000000) MX[B]E
[18] -1 1 0x7d000000 - 0x7dffffff (0x1000000) MX[B]E
[19] -1 1 0x00180000 - 0x001fffff (0x80000) MX[B]E
[20] -1 1 0x00132000 - 0x00133fff (0x2000) MX[B]E
[21] -1 1 0x00130000 - 0x00131fff (0x2000) MX[B]E
[22] -1 1 0x0012e000 - 0x0012ffff (0x2000) MX[B]E
[23] -1 1 0x0012c000 - 0x0012dfff (0x2000) MX[B]E
[24] -1 2 0x00ffffff - 0x00ffffff (0x1) IX[B]
[25] -1 2 0x00000000 - 0x00000000 (0x1) IX[B]
[26] -1 1 0x00ffffff - 0x00ffffff (0x1) IX[B]
[27] -1 1 0x00000000 - 0x00000000 (0x1) IX[B]
[28] -1 2 0x00000300 - 0x000003ff (0x100) IX[B]E
[29] -1 1 0x00000300 - 0x000003ff (0x100) IX[B]E
[30] -1 1 0x00000500 - 0x000005ff (0x100) IX[B]E
[31] -1 1 0x00000400 - 0x000004ff (0x100) IX[B]E
(II) LoadModule: "extmod"
(II) Loading /usr/local/lib/xorg/modules/extensions//libextmod.so
(II) Module extmod: vendor="X.Org Foundation"
compiled for 7.2.0, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 0.3
(II) Loading extension SHAPE
(II) Loading extension MIT-SUNDRY-NONSTANDARD
(II) Loading extension BIG-REQUESTS
(II) Loading extension SYNC
(II) Loading extension MIT-SCREEN-SAVER
(II) Loading extension XC-MISC
(II) Loading extension XFree86-VidModeExtension
(II) Loading extension XFree86-Misc
(II) Loading extension XFree86-DGA
(II) Loading extension DPMS
(II) Loading extension TOG-CUP
(II) Loading extension Extended-Visual-Information
(II) Loading extension XVideo
(II) Loading extension XVideo-MotionCompensation
(II) Loading extension X-Resource
(II) LoadModule: "record"
(II) Loading /usr/local/lib/xorg/modules/extensions//librecord.so
(II) Module record: vendor="X.Org Foundation"
compiled for 7.2.0, module version = 1.13.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 0.3
(II) Loading extension RECORD
(II) LoadModule: "dbe"
(II) Loading /usr/local/lib/xorg/modules/extensions//libdbe.so
(II) Module dbe: vendor="X.Org Foundation"
compiled for 7.2.0, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 0.3
(II) Loading extension DOUBLE-BUFFER
(II) LoadModule: "xtrap"
(II) Loading /usr/local/lib/xorg/modules/extensions//libxtrap.so
(II) Module xtrap: vendor="X.Org Foundation"
compiled for 7.2.0, module version = 1.0.0
Module class: X.Org Server Extension
ABI class: X.Org Server Extension, version 0.3
(II) Loading extension DEC-XTRAP
(II) LoadModule: "freetype"
(II) Loading /usr/local/lib/xorg/modules/fonts//libfreetype.so
dlopen: ld.so.1: Xorg: fatal: relocation error: file
/usr/local/lib/xorg/modules/fonts//libfreetype.so: symbol
FreeTypeRegisterFontFileFunctions: referenced symbol not found
(EE) Failed to load /usr/local/lib/xorg/modules/fonts//libfreetype.so
(II) UnloadModule: "freetype"
(EE) Failed to load module "freetype" (loader failed, 7)
(II) LoadModule: "type1"
(II) Loading /usr/local/lib/xorg/modules/fonts//libtype1.so
(II) Module type1: vendor="X.Org Foundation"
compiled for 7.2.0, module version = 1.0.2
Module class: X.Org Font Renderer
ABI class: X.Org Font Renderer, version 0.5
(II) Loading font Type1
(II) LoadModule: "sunffb"
(II) Loading /usr/local/lib/xorg/modules/drivers//sunffb_drv.so
(II) Module sunffb: vendor="X.Org Foundation"
compiled for 7.2.0, module version = 1.1.0
Module class: X.Org Video Driver
ABI class: X.Org Video Driver, version 1.1
(II) LoadModule: "mouse"
(II) Loading /usr/local/lib/xorg/modules/input//mouse_drv.so
(II) Module mouse: vendor="X.Org Foundation"
compiled for 7.2.0, module version = 1.1.1
Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 0.7
(II) LoadModule: "kbd"
(II) Loading /usr/local/lib/xorg/modules/input//kbd_drv.so
(II) Module kbd: vendor="X.Org Foundation"
compiled for 7.2.0, module version = 1.1.0
Module class: X.Org XInput Driver
ABI class: X.Org XInput driver, version 0.7
(II) SUNFFB: driver for Creator, Creator 3D and Elite 3D
(II) resource ranges after probing:
[0] -1 2 0xffffffff - 0xffffffff (0x1) MX[B]
[1] -1 2 0x000f0000 - 0x000fffff (0x10000) MX[B]
[2] -1 2 0x000c0000 - 0x000effff (0x30000) MX[B]
[3] -1 2 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[4] -1 1 0xffffffff - 0xffffffff (0x1) MX[B]
[5] -1 1 0x000f0000 - 0x000fffff (0x10000) MX[B]
[6] -1 1 0x000c0000 - 0x000effff (0x30000) MX[B]
[7] -1 1 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[8] -1 2 0x00100000 - 0x001fffff (0x100000) MX[B]E
[9] -1 1 0x0012a000 - 0x0012bfff (0x2000) MX[B]E
[10] -1 1 0x00128000 - 0x00129fff (0x2000) MX[B]E
[11] -1 1 0x00126000 - 0x00127fff (0x2000) MX[B]E
[12] -1 1 0x00124000 - 0x00125fff (0x2000) MX[B]E
[13] -1 1 0x01000000 - 0x01ffffff (0x1000000) MX[B]E
[14] -1 1 0x00122000 - 0x00123fff (0x2000) MX[B]E
[15] -1 1 0x00120000 - 0x00121fff (0x2000) MX[B]E
[16] -1 1 0x00100000 - 0x0011ffff (0x20000) MX[B]E
[17] -1 1 0x7e000000 - 0x7fffffff (0x2000000) MX[B]E
[18] -1 1 0x7d000000 - 0x7dffffff (0x1000000) MX[B]E
[19] -1 1 0x00180000 - 0x001fffff (0x80000) MX[B]E
[20] -1 1 0x00132000 - 0x00133fff (0x2000) MX[B]E
[21] -1 1 0x00130000 - 0x00131fff (0x2000) MX[B]E
[22] -1 1 0x0012e000 - 0x0012ffff (0x2000) MX[B]E
[23] -1 1 0x0012c000 - 0x0012dfff (0x2000) MX[B]E
[24] -1 2 0x00ffffff - 0x00ffffff (0x1) IX[B]
[25] -1 2 0x00000000 - 0x00000000 (0x1) IX[B]
[26] -1 1 0x00ffffff - 0x00ffffff (0x1) IX[B]
[27] -1 1 0x00000000 - 0x00000000 (0x1) IX[B]
[28] -1 2 0x00000300 - 0x000003ff (0x100) IX[B]E
[29] -1 1 0x00000300 - 0x000003ff (0x100) IX[B]E
[30] -1 1 0x00000500 - 0x000005ff (0x100) IX[B]E
[31] -1 1 0x00000400 - 0x000004ff (0x100) IX[B]E
(**) SUNFFB(0): Option "SWcursor" "True"
(==) SUNFFB(0): RGB weight 888
(==) SUNFFB(0): Default visual is TrueColor
(==) SUNFFB(0): Using gamma correction (1.0, 1.0, 1.0)
(**) SUNFFB(0): Using SW cursor
(II) Loading sub module "fb"
(II) LoadModule: "fb"
(II) Loading /usr/local/lib/xorg/modules//libfb.so
(II) Module fb: vendor="X.Org Foundation"
compiled for 7.2.0, module version = 1.0.0
ABI class: X.Org ANSI C Emulation, version 0.3
(II) Loading sub module "xaa"
(II) LoadModule: "xaa"
(II) Loading /usr/local/lib/xorg/modules//libxaa.so
(II) Module xaa: vendor="X.Org Foundation"
compiled for 7.2.0, module version = 1.2.0
ABI class: X.Org Video Driver, version 1.1
(II) Loading sub module "dbe"
(II) LoadModule: "dbe"
(II) Reloading /usr/local/lib/xorg/modules/extensions//libdbe.so
(II) Loading extension DOUBLE-BUFFER
(==) SUNFFB(0): DPI set to (75, 75)
(==) SUNFFB(1): RGB weight 888
(==) SUNFFB(1): Default visual is TrueColor
(==) SUNFFB(1): Using gamma correction (1.0, 1.0, 1.0)
(==) SUNFFB(1): Using HW cursor
(II) Loading sub module "fb"
(II) LoadModule: "fb"
(II) Reloading /usr/local/lib/xorg/modules//libfb.so
(II) Loading sub module "xaa"
(II) LoadModule: "xaa"
(II) Reloading /usr/local/lib/xorg/modules//libxaa.so
(II) Loading sub module "ramdac"
(II) LoadModule: "ramdac"
(II) Loading /usr/local/lib/xorg/modules//libramdac.so
(II) Module ramdac: vendor="X.Org Foundation"
compiled for 7.2.0, module version = 0.1.0
ABI class: X.Org Video Driver, version 1.1
(II) Loading sub module "dbe"
(II) LoadModule: "dbe"
(II) Reloading /usr/local/lib/xorg/modules/extensions//libdbe.so
(II) Loading extension DOUBLE-BUFFER
(==) SUNFFB(1): DPI set to (75, 75)
(--) Depth 24 pixmap format is 32 bpp
(II) do I need RAC? Yes, I do.
(II) resource ranges after preInit:
[0] -1 2 0xffffffff - 0xffffffff (0x1) MX[B]
[1] -1 2 0x000f0000 - 0x000fffff (0x10000) MX[B]
[2] -1 2 0x000c0000 - 0x000effff (0x30000) MX[B]
[3] -1 2 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[4] -1 1 0xffffffff - 0xffffffff (0x1) MX[B]
[5] -1 1 0x000f0000 - 0x000fffff (0x10000) MX[B]
[6] -1 1 0x000c0000 - 0x000effff (0x30000) MX[B]
[7] -1 1 0x00000000 - 0x0009ffff (0xa0000) MX[B]
[8] -1 2 0x00100000 - 0x001fffff (0x100000) MX[B]E
[9] -1 1 0x0012a000 - 0x0012bfff (0x2000) MX[B]E
[10] -1 1 0x00128000 - 0x00129fff (0x2000) MX[B]E
[11] -1 1 0x00126000 - 0x00127fff (0x2000) MX[B]E
[12] -1 1 0x00124000 - 0x00125fff (0x2000) MX[B]E
[13] -1 1 0x01000000 - 0x01ffffff (0x1000000) MX[B]E
[14] -1 1 0x00122000 - 0x00123fff (0x2000) MX[B]E
[15] -1 1 0x00120000 - 0x00121fff (0x2000) MX[B]E
[16] -1 1 0x00100000 - 0x0011ffff (0x20000) MX[B]E
[17] -1 1 0x7e000000 - 0x7fffffff (0x2000000) MX[B]E
[18] -1 1 0x7d000000 - 0x7dffffff (0x1000000) MX[B]E
[19] -1 1 0x00180000 - 0x001fffff (0x80000) MX[B]E
[20] -1 1 0x00132000 - 0x00133fff (0x2000) MX[B]E
[21] -1 1 0x00130000 - 0x00131fff (0x2000) MX[B]E
[22] -1 1 0x0012e000 - 0x0012ffff (0x2000) MX[B]E
[23] -1 1 0x0012c000 - 0x0012dfff (0x2000) MX[B]E
[24] -1 2 0x00ffffff - 0x00ffffff (0x1) IX[B]
[25] -1 2 0x00000000 - 0x00000000 (0x1) IX[B]
[26] -1 1 0x00ffffff - 0x00ffffff (0x1) IX[B]
[27] -1 1 0x00000000 - 0x00000000 (0x1) IX[B]
[28] -1 2 0x00000300 - 0x000003ff (0x100) IX[B]E
[29] -1 1 0x00000300 - 0x000003ff (0x100) IX[B]E
[30] -1 1 0x00000500 - 0x000005ff (0x100) IX[B]E
[31] -1 1 0x00000400 - 0x000004ff (0x100) IX[B]E
(II) /dev/fb4: Detected FFB2+/vertical, Z-buffer, Single-buffered.
(II) /dev/fb4: BT9068 (PAC1) ramdac detected (with inverted cursor control)
(II) /dev/fb4: Detected Creator/Creator3D
(II) SUNFFB(0): Using XFree86 Acceleration Architecture (XAA)
Screen to screen bit blits
Solid filled rectangles
8x8 mono pattern filled rectangles
Indirect CPU to Screen color expansion
Solid Lines
Dashed Lines
Driver provided ScreenToScreenBitBlt replacement
Driver provided WritePixmap replacement
(II) /dev/fb4: Using acceleration
(==) SUNFFB(0): Backing store disabled
(==) SUNFFB(0): Silken mouse disabled
(II) /dev/fb4: DGA support initialized.
(==) RandR enabled
(II) /dev/fb5: Detected FFB2+/vertical, Z-buffer, Single-buffered.
(II) /dev/fb5: BT9068 (PAC1) ramdac detected (with inverted cursor control)
(II) /dev/fb5: Detected Creator/Creator3D
(II) SUNFFB(1): Using XFree86 Acceleration Architecture (XAA)
Screen to screen bit blits
Solid filled rectangles
8x8 mono pattern filled rectangles
Indirect CPU to Screen color expansion
Solid Lines
Dashed Lines
Driver provided ScreenToScreenBitBlt replacement
Driver provided WritePixmap replacement
(II) /dev/fb5: Using acceleration
(==) SUNFFB(1): Backing store disabled
(==) SUNFFB(1): Silken mouse disabled
(II) /dev/fb5: DGA support initialized.
(==) RandR enabled
(II) Entity 0 shares no resources
(II) Entity 1 shares no resources
(II) Initializing built-in extension MIT-SHM
(II) Initializing built-in extension XInputExtension
(II) Initializing built-in extension XTEST
(II) Initializing built-in extension XKEYBOARD
(II) Initializing built-in extension XC-APPGROUP
(II) Initializing built-in extension XAccessControlExtension
(II) Initializing built-in extension SECURITY
(II) Initializing built-in extension XINERAMA
(II) Initializing built-in extension XFIXES
(II) Initializing built-in extension XFree86-Bigfont
(II) Initializing built-in extension RENDER
(II) Initializing built-in extension RANDR
(II) Initializing built-in extension COMPOSITE
(II) Initializing built-in extension DAMAGE
(II) Initializing built-in extension XEVIE
(**) Option "Protocol" "auto"
(II) Mouse0: Setting Device option to "/dev/mouse"
(**) Mouse0: Protocol: VUID
(**) Option "CorePointer"
(**) Mouse0: Core Pointer
(**) Option "Device" "/dev/mouse"
(II) Mouse0: Setting Buttons option to "3"
(==) Mouse0: Emulate3Buttons, Emulate3Timeout: 50
(**) Option "ZAxisMapping" "4 5 6 7"
(**) Mouse0: ZAxisMapping: buttons 4, 5, 6 and 7
(**) Mouse0: Buttons: 11
(**) Option "CoreKeyboard"
(**) Keyboard0: Core Keyboard
(II) Keyboard0: Opened device "/dev/kbd"
(**) Option "AutoRepeat" "500 30"
(**) Option "XkbRules" "xorg"
(**) Keyboard0: XkbRules: "xorg"
(**) Option "XkbModel" "pc105"
(**) Keyboard0: XkbModel: "pc105"
(**) Option "XkbLayout" "us"
(**) Keyboard0: XkbLayout: "us"
(**) Option "CustomKeycodes" "off"
(**) Keyboard0: CustomKeycodes disabled
(II) XINPUT: Adding extended input device "Keyboard0" (type: KEYBOARD)
(II) XINPUT: Adding extended input device "Mouse0" (type: MOUSE)
(--) Keyboard0: Keyboard type: USB (6)
(--) Keyboard0: Keyboard layout: 33
(WW) Couldn't load XKB keymap, falling back to pre-XKB keymap
(II) 3rd Button detected: disabling emulate3Button
sh-3.00# ls -al /dev/fb
lrwxrwxrwx 1 root root 39 Feb 22 18:38 /dev/fb ->
/devices/upa@8,480000/SUNW,ffb@0,0:ffb0
sh-3.00# uname -a
SunOS mb1x-ws1 5.11 snv_41 sun4u sparc SUNW,Sun-Blade-1000
sh-3.00# isainfo -v
64-bit sparcv9 applications
vis2 vis
32-bit sparc applications
vis2 vis v8plus div32 mul32
sh-3.00# isainfo -k
sparcv9
sh-3.00#
no regards
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: blastwave package handling [was Re: Re: joining
Sun]
Posted:
Mar 21, 2007 7:09 AM
in response to: dclarke
|
|
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 <james dot d dot carlson at sun dot com>
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 at opensolaris dot org
|
|
|
|
|
Posts:
1,674
From:
Registered:
7/15/05
|
|
|
|
Re: blastwave package handling [was Re: Re:
joining Sun]
Posted:
Mar 31, 2007 12:10 PM
in response to: dclarke
To: OpenSolaris » discuss
|
|
> 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 documentation clearly states that a patch must never deliver new functionality.
If new functionlity is delivered, it must be performed via a new revision of the 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?"
You guys (Blastwave) are numero uno. The #1 freeware organization for Solaris. No questions asked.
But you have some pretty big problems. Your biggest problem is not whether to patch or package, the docs are clear on that. The problems you (as a group) have is that you're not fully System V compliant, i.e. you deliver everything under one directory, /opt/csw/, rather than following the System V spec. And that's a big problem in my book, an architectural one. Yes you've said a million times it was done "to keep everything in one place" and "for NFS mount reasons", but that doesn't cut it. Which is why guys like me have to roll out their own software stack. And it's a real shame that it has to be done twice because of that.
The second problem is that no proper integration with Solaris takes place. For instance, there is no consistent class framework that behaves in a predictable way. "Will work out of the box" automation is minimal, if it even exists. Startup scripts don't think all the scenarios through, and are very minimal.
|
|
|
|
|
Posts:
5,504
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: blastwave package handling [was Re: Re:
joining Sun]
Posted:
Apr 1, 2007 11:02 PM
in response to: ux-admin
|
|
UNIX admin wrote:
>> 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 documentation clearly states that a patch must never deliver new functionality.
What documentation is that? It's clearly buggy.
--
-Alan Coopersmith- alan dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
29
From:
Registered:
6/14/05
|
|
|
|
Re: blastwave package handling [was Re: Re: joining Sun]
Posted:
Mar 21, 2007 5:18 PM
in response to: carlsonj
To: OpenSolaris » discuss
|
|
> 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
|
|
|
|
|
Posts:
1,495
From:
Registered:
5/18/05
|
|
|
|
Re: Re: blastwave package handling [was Re: Re: joining
Sun]
Posted:
Mar 21, 2007 6:42 PM
in response to: snorbert
|
|
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 at opensolaris dot org
|
|
|
|
|
Posts:
1,539
From:
Cobourg Ontario Canada
Registered:
4/27/05
|
|
|
|
Re: Re: blastwave package handling
Posted:
Mar 21, 2007 7:50 PM
in response to: plocher
|
|
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 at opensolaris dot org
|
|
|
|
|
Posts:
1,539
From:
Cobourg Ontario Canada
Registered:
4/27/05
|
|
|
|
Re: Re: blastwave package handling [was Re: Re:
joining Sun]
Posted:
Mar 21, 2007 7:39 PM
in response to: snorbert
|
|
<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 users at lists dot blastwave dot org 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
dclarke at blastwave dot org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,810
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: blastwave package handling [was Re: Re:
joining Sun]
Posted:
Mar 22, 2007 5:43 AM
in response to: snorbert
|
|
Jason Ozolins writes:
> > Jason Ozolins writes:
> > 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.
It doesn't explain why we use patches, and the existence of a running
instance doesn't have much to do with it.
Internally, patches use what are called "sparse" packages. If you
look inside a patch, you'll see bunch of somewhat ordinary-looking
packages. What's special about them is that they contain only *some*
of the files that were in the original package -- specifically, the
files that changed. The system relies on the fact that it can
overwrite the package and only those files will be touched.
> > 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...
Indeed.
> Remove package, shared libs,
That's not correct. It's possible to use the admin(4) file to get a
different behavior out of pkgadd.
> kill daemon for duration of upgrade, [probably killing running telnet sessions in the process]
That *may* be necessary, but it has essentially nothing to do with
whether you're using a package or a patch.
The key issues are not related to the delivery mechanism, but rather
due to aspects of what's being delivered. The packaging system (which
is used by patching under the covers) always writes to a new file and
then moves the object into place. This means that it's actually safe
to do an overwrite-install of a package while the object is running,
provided that:
- the object already has all the files (including shared libraries)
open that it's going to need, and isn't going to lazy-load or
dlopen after you've started the upgrade process.
- any other changes made to the system as a part of the package
install process (such as rewriting configuration files) are not of
a nature that will "confuse" this running process.
It's in enumerating those issues, and following the logical chains
through other libraries and options, that the complexity arises. This
is why many patches from Sun recommend single-user (to make sure that
nothing's running, as we can't guarantee the consistency above) and
quite a few say "reboot immediate."
Blastwave's approach has essentially the same underlying issues, even
if the user experience is different.
> reinstall package, maybe cream config files somewhere in the process.
As for configuration files that get removed or damaged in the upgrade
process, that's an upstream packaging error. The package creator has
to be aware of how the upgrade will take place, and plan for it so
that the necessary information isn't nuked in the process. Inside
Sun, we handle this problem through a variety of review and testing
procedures (the ARC is part of this, but there are many other parts).
I'm not sure how blastwave handles review of packaging rules and
upgrade planning -- that's something you should take up with them (and
probably not on this list).
The same is actually true for patches.
> 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.
I strongly agree with that. The quality of the upgrade experience has
an enormous impact on whether a platform is viable at all in a
production environment.
I don't think, though, that "decent package management" is entirely or
even primarily a feature of the packaging software itself. A huge
amount of the effort rests on the project teams who package and
deliver the software -- if they don't think through the upgrade
scenarios clearly, there's not much that even the most sophisticated
packaging tools can do to save them.
Good tools can help, but there's no magic bullet here.
--
James Carlson, Solaris Networking <james dot d dot carlson at sun dot com>
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 at opensolaris dot org
|
|
|
|
|
Posts:
173
From:
London, Canada
Registered:
6/14/05
|
|
|
|
Re: Re: blastwave package handling [was Re: Re:
joining Sun]
Posted:
Mar 23, 2007 1:00 AM
in response to: carlsonj
|
|
On 3/22/07, James Carlson <james dot d dot carlson at sun dot com> wrote:
> I don't think, though, that "decent package management" is entirely or
> even primarily a feature of the packaging software itself. A huge
> amount of the effort rests on the project teams who package and
> deliver the software -- if they don't think through the upgrade
> scenarios clearly, there's not much that even the most sophisticated
> packaging tools can do to save them.
>
> Good tools can help, but there's no magic bullet here.
Indeed.
Several months ago a friend of mine running Debian did an `apt-get
dist-upgrade'. Among other things, it upgraded apache2 and squid to
newer versions, which took advantage of epoll().
epoll() is only available in Linux 2.6. These packages were built on
2.6, which made use of this newly available syscall. These packages
were then deployed to systems running 2.4 kernels (also packaged by
the same organization, and not obsoleted.) The resulting crashes were
really quite spectacular.
--
Eric Enright
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,109
From:
Registered:
6/14/05
|
|
|
|
Re: Re: blastwave package handling [was Re:
Re: joining Sun]
Posted:
Mar 23, 2007 12:12 PM
in response to: eenright
|
|
On Friday 23 March 2007 01:00 am, Eric Enright wrote:
> Indeed.
>
> Several months ago a friend of mine running Debian did an `apt-get
> dist-upgrade'. Among other things, it upgraded apache2 and squid to
> newer versions, which took advantage of epoll().
>
> epoll() is only available in Linux 2.6. These packages were built on
> 2.6, which made use of this newly available syscall. These packages
> were then deployed to systems running 2.4 kernels (also packaged by
> the same organization, and not obsoleted.) The resulting crashes were
> really quite spectacular.
A friend of mine runs Debian also, and recentely had a different problem where
only a 32-bit version was available for a package after he did a
dist-upgrade, and that caused him to have to revert back to 32-bit and/or
possibly UMP to get his system running.
The binary compatibility in Solaris/OpenSolaris is something that doesn't get
the respect it deserves in these cases.
--
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 at opensolaris dot org
|
|
|
|
|
Posts:
581
From:
CZ
Registered:
3/21/06
|
|
|
|
Re: Re: blastwave package handling [was Re:
Re: joining Sun]
Posted:
Mar 23, 2007 1:15 PM
in response to: aland
|
|
Hi,
Alan DuBoff píše v pá 23. 03. 2007 v 12:12 -0700:
> On Friday 23 March 2007 01:00 am, Eric Enright wrote:
> > Indeed.
> >
> > Several months ago a friend of mine running Debian did an `apt-get
> > dist-upgrade'. Among other things, it upgraded apache2 and squid to
> > newer versions, which took advantage of epoll().
> >
> > epoll() is only available in Linux 2.6. These packages were built on
> > 2.6, which made use of this newly available syscall. These packages
> > were then deployed to systems running 2.4 kernels (also packaged by
> > the same organization, and not obsoleted.) The resulting crashes were
> > really quite spectacular.
>
> A friend of mine runs Debian also, and recentely had a different problem where
> only a 32-bit version was available for a package after he did a
> dist-upgrade, and that caused him to have to revert back to 32-bit and/or
> possibly UMP to get his system running.
>
> The binary compatibility in Solaris/OpenSolaris is something that doesn't get
> the respect it deserves in these cases.
>
OK, boys, could you stop with this thread, please? I has been using
Debian (and am still on some places) for aprox. 10 years. I met several
problems, but:
a) Eric case - wasn't it Debian testing (Etch), where Linux 2.4 is not
officially supported? In the other case it was significant bug in
buildd.
b) Alan case - x86/amd64 platform or some other? Because amd64 is not
supported officially in Debian stable (Sarge).
So, please, if you are using testing version, please, expect that it is
not stable release. The same if you are using backports. If you are
upgrading your release, read release notes.
Linux has +&-, Debian has +&-, OSOL has +&-
And, again, please, stop with this ..., it is not good for OSOL,
community, world, peace etc. ;-)
Have a nice weekend
Milan
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,674
From:
Registered:
7/15/05
|
|
|
|
Re: blastwave package handling [was Re: Re: joining Sun]
Posted:
Mar 31, 2007 12:30 PM
in response to: snorbert
To: OpenSolaris » discuss
|
|
> 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 not allowed to deliver upgrades or otherwise upgrade software on Solaris.
Patches are explicitly not allowed to deliver new functionality.
Upgrades do that.
That's an architectural difference.
> 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.
It pains me to read such things.
Here you are, putting me smack dab in the middle of a moral dilemma.
If I released my software stack to the public, it would help people like you out, because it does exactly what you need it do to. On the other hand, I will pay dearly with my privacy gone. This is why I dislike moral dilemmas to the extreme.
So the best thing I can tell you right now, until I have churned on this dilemma some more is, if you are adamant about running things on Solaris, you'll have to roll out your own software stack, and do rigorous quality control, like Sun does.
It's not as hard as it sounds. It just takes time if you're alone.
> 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.
You make a valid point.
However, let's take your case into consideration: YOU are THE sysadmin. YOU decide what will be implemented, NOT developers or the management.
A real sysadmin is a phenomenal developer, just as a real developer is also a phenomenal sysadmin. So YOU should be in charge of telling those guys what it is that they are going to be doing. They've got no business peddling any Linux or any other nonsense.
Management also shouldn't be sticking their nose in these decisions unless they have the necessary technical skills, which most of the time they don't.
Which is why you crush them with technical details as arguments in the meetings, so that next time they DREAD going into a meeting where they know you're going to be present, and where they'll watch what they say in front of you or risk being exposed as technically incompetent as they normally are.
Ally with technically skilled managers so that the company can be pushed forward and prosper and so that IT will be an asset and not a liability.
Crush incompetent managers by exposing them when the opportunity presents itself and help the company prosper by removing people who are inconstructive and look only to advance themselves.
|
|
|
|
|
Posts:
5,504
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: blastwave package handling [was Re: Re: joining
Sun]
Posted:
Apr 1, 2007 11:02 PM
in response to: ux-admin
|
|
UNIX admin wrote:
> Patches are not allowed to deliver upgrades or otherwise upgrade software on Solaris.
> Patches are explicitly not allowed to deliver new functionality.
Wrong. Patches have been delivering new functionality into Solaris
for years. One of my first tasks at Sun when I started in 1999 was
working on the patches that updated Xsun from X11R6.0 to X11R6.4 and
added functionality such as Xinerama.
--
-Alan Coopersmith- alan dot coopersmith at sun dot com
Sun Microsystems, Inc. - X Window System Engineering
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,172
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: blastwave package handling [was Re: Re: joining
Sun]
Posted:
Apr 2, 2007 10:03 AM
in response to: ux-admin
|
|
UNIX admin wrote:
> Patches are not allowed to deliver upgrades or otherwise upgrade software on Solaris.
> Patches are explicitly not allowed to deliver new functionality.
>
> Upgrades do that.
>
Patches are supposed to amend existing packages in a hopefully coherent
fashion. Whether that amendment implements a new feature, fixes a bug
or whatever is a function of the intent of the patch developer, not
any intrinsic attribute of the patch or rule at Sun. Unfortunately,
we don't rev package version numbers when we patch them; our packaging
system is unaware of patches.
We need to make the distinction between patching and upgrading
go away; package versioning needs to be implemented.
- Bart
--
Bart Smaalders Solaris Kernel Performance
barts at cyber dot eng dot sun dot com http://blogs.sun.com/barts
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
315
From:
US
Registered:
4/27/05
|
|
|
|
Re: joining Sun
Posted:
Mar 19, 2007 9:49 AM
in response to: imurdock
|
|
On 3/19/07, Ian Murdock <imurdock at imurdock dot com> wrote:
> Hi all,
>
> It's being announced today that I'm joining Sun as chief operating
> platforms officer, which basically means I'll be in charge of Sun's
> operating system strategy, spanning Solaris and Linux. I just posted the
> announcement on my blog (http://ianmurdock.com/2007/03/19/joining-sun/),
> and it'll likely be making the rounds soon. Just wanted to
> make sure you heard the news directly from me and to introduce myself.
Cool. Very cool.
--Stefan
--
Stefan Teleman
KDE e.V.
stefan dot teleman at gmail dot com
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,177
From:
US
Registered:
6/24/05
|
|
|
|
Re: joining Sun
Posted:
Mar 19, 2007 9:51 AM
in response to: imurdock
To: OpenSolaris » discuss
|
|
I just wanted
> to say hello, and to make sure you heard the news
> directly from me.
>
> Later,
>
> -ian
> --
> Ian Murdock
> http://ianmurdock.com/
Wow, I remember you. You were debIAN when Debian was cool. Mahalo.
|
|
|
|
|
Posts:
374
From:
US
Registered:
12/9/05
|
|
|
|
Re: joining Sun
Posted:
Mar 19, 2007 12:27 PM
in response to: imurdock
|
|
On Mar 19, 2007, at 11:53 AM, Ian Murdock wrote:
> Hi all,
>
> It's being announced today that I'm joining Sun as chief operating
> platforms officer, which basically means I'll be in charge of Sun's
> operating system strategy, spanning Solaris and Linux. I just
> posted the
> announcement on my blog (http://ianmurdock.com/2007/03/19/joining-
> sun/),
> and it'll likely be making the rounds soon. Just wanted to
> make sure you heard the news directly from me and to introduce myself.
Hi, Ian, welcome to the community!
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!
/dale_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
50
From:
Registered:
3/17/07
|
|
|
|
Re: joining Sun
Posted:
Mar 21, 2007 1:29 PM
in response to: daleg
|
|
On 3/19/07, Dale Ghent <daleg at elemental dot org> 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 at opensolaris dot org
|
|
|
|
|
Posts:
1,539
From:
Cobourg Ontario Canada
Registered:
4/27/05
|
|
|
|
Re: joining Sun
Posted:
Mar 21, 2007 1:38 PM
in response to: imurdock
|
|
<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
dclarke at blastwave dot org
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
278
From:
Registered:
5/12/06
|
|
|
|
Re: joining Sun
Posted:
Mar 21, 2007 2:32 PM
in response to: dclarke
|
|
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 at opensolaris dot org
|
|
|
|
|
Posts:
1,109
From:
Registered:
6/14/05
|
|
|
|
Re: joining Sun
Posted:
Mar 21, 2007 10:30 PM
in response to: erast
|
|
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 at opensolaris dot org
|
|
|
|
|
Posts:
50
From:
Registered:
3/17/07
|
|
|
|
Re: joining Sun
Posted:
Mar 26, 2007 11:56 AM
in response to: aland
|
|
On 3/21/07, Alan DuBoff <Alan dot DuBoff at sun dot com> wrote:
> Seriously, I hope to see Ian active with the OpenSolaris community.;-)
Absolutely. My latency may be terrible though, particularly in the beginning
(as you've no doubt already noticed :-). Sorry about that.
-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 at opensolaris dot org
|
|
|
|
|
Posts:
1,109
From:
Registered:
6/14/05
|
|
|
|
Re: joining Sun
Posted:
Mar 26, 2007 4:25 PM
in response to: imurdock
|
|
On Monday 26 March 2007 11:56 am, Ian Murdock wrote:
> On 3/21/07, Alan DuBoff <Alan dot DuBoff at sun dot com> wrote:
> > Seriously, I hope to see Ian active with the OpenSolaris community.;-)
>
> Absolutely. My latency may be terrible though, particularly in the
> beginning (as you've no doubt already noticed :-). Sorry about that.
Understood, and please do participate whenever you have time.
I saw you at MPK17 today, and was walking in just as you were heading up the
stairs. I was going to say hi, but your cell phone rang.;-)
--
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 at opensolaris dot org
|
|
|
|
|
Posts:
77
From:
Registered:
1/21/07
|
|
|
|
Re: joining Sun
Posted:
Mar 22, 2007 5:42 AM
in response to: imurdock
|
|
On 3/21/07, Ian Murdock <imurdock at imurdock dot com> wrote:
>
> 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...
As a Linux user who has recently started working with the OpenSolaris
kernel for a project, I have been thinking about this as well.
What I personally find important in Linux is:
- the user experience, mostly embodied by the KDE desktop environment.
I don't like Gnome, so I don't like the default Solaris desktop
environment. I heard that there is a KDE project for OpenSolaris, so
that is great. If most of the GUI programs would run on OpenSolaris as
well, then the biggest challenge has been overwon I think.
- then there are the command line programs. There might be a good
reason for this, but I feel that some of the Solaris-shipped tools are
inferior to the GNU tools. For example, I don't see a reason why a
simple recursive grep with 'grep -R' does not work on Solaris. Why
there are two greps is something I do not understand either.
I do not get the way man works either. On Linux, you would just do
"man cat" or "man vi", and it would just give you the correct man
page. Even 'man man' doesn't work here. (I'm beginning to wonder
whether this may be because the man pages are not installed... could
this be? man man should work, right?)
I agree that a lot of this frustration is more because it is unknown
and different than what I am used to. But I think this will be the
case for a lot of users which come from Linux, and if Solaris wants to
make these people change OS, this should be taken into account.
- the actual kernel is not very important from a user point of view I
think. What is important is the hardware support, and I am not sure to
what extent OpenSolaris is good at this. For example, I have an Acer
laptop with an embedded webcam. For Linux, there was reasonably
quickly a driver (gspca) available. I don't know if this would have
been the case with OpenSolaris. Of course, this also depends on the
size of the developer community and I think that's were Linux has a
plus.
As a developer, the kernel code of OpenSolaris seems much more
documented and organised than that of Linux, which is definitely a
plus.
If OpenSolaris can get these three points right, I believe it could be
a great alternative...
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
77
From:
Registered:
1/21/07
|
|
|
|
Re: joining Sun
Posted:
Mar 22, 2007 5:51 AM
in response to: tdescham
|
|
Another thing that came to mind: the fact that Solaris needs a primary
partition to install on is a big problem in my view. I had set-up my
disk so there were 3 logical partitions of about 15GB for operating
systems (linux and I hoped OpenSolaris as well). Obviously, Solaris
couldn't install and I am not keen on repartitioning my whole disk.
Adding a new disk isn't a real option either since this is a laptop.
Probably there is a good reason for this partition way, but IF this
could change, it would definitely lower the barrier from Linux I
think.
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,154
From:
US
Registered:
6/14/05
|
|
|
|
Re: joining Sun
Posted:
Mar 22, 2007 11:46 AM
in response to: tdescham
|
|
On 22/03/07, Thomas De Schampheleire <patrickdepinguin at gmail dot com> wrote:
> Another thing that came to mind: the fact that Solaris needs a primary
> partition to install on is a big problem in my view. I had set-up my
> disk so there were 3 logical partitions of about 15GB for operating
> systems (linux and I hoped OpenSolaris as well). Obviously, Solaris
> couldn't install and I am not keen on repartitioning my whole disk.
> Adding a new disk isn't a real option either since this is a laptop.
I know the install "folks" are working with others to eventually
support installing Solaris in an extended partition. In the meantime,
a program like PartitionMagic, gparted, qtparted, etc. can help you
re-arrange your partitions (non-destructively, though you should
BACKUP YOUR DATA FIRST).
This a known issue, but one that didn't matter so much in the past,
since, as others pointed out, Solaris is used to being the only one on
the drive.
--
"Less is only more where more is no good." --Frank Lloyd Wright
Shawn Walker, Software and Systems Analyst
binarycrusader at gmail dot com - http://binarycrusader.blogspot.com/
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
186
From:
Shanghai.China
Registered:
9/6/06
|
|
|
|
Re: joining Sun
Posted:
Mar 22, 2007 6:02 AM
in response to: tdescham
|
|
yes, I'm also a long time Linux user/developer who has recently working on Solaris for a research project base on the DTrace tool. It's true there're plenty of powerful tools in Solaris, but some habitual Linux tools are miss or different. And this makes me feel uncomfortable.
Baseing on Solaris kernel's excellent performance and adding Linux tools on it, it is a good way to popularize the Solaris. I think the combination is very important if Sun wants to scramble for the desktop users and the Linux developers.
2007/3/22, Thomas De Schampheleire <patrickdepinguin at gmail dot com>:
On 3/21/07, Ian Murdock <imurdock at imurdock dot com> wrote:
>
> 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...
As a Linux user who has recently started working with the OpenSolaris
kernel for a project, I have been thinking about this as well.
What I personally find important in Linux is:
- the user experience, mostly embodied by the KDE desktop environment.
I don't like Gnome, so I don't like the default Solaris desktop
environment. I heard that there is a KDE project for OpenSolaris, so
that is great. If most of the GUI programs would run on OpenSolaris as
well, then the biggest challenge has been overwon I think.
- then there are the command line programs. There might be a good
reason for this, but I feel that some of the Solaris-shipped tools are
inferior to the GNU tools. For example, I don't see a reason why a
simple recursive grep with 'grep -R' does not work on Solaris. Why
there are two greps is something I do not understand either.
I do not get the way man works either. On Linux, you would just do
"man cat" or "man vi", and it would just give you the correct man
page. Even 'man man' doesn't work here. (I'm beginning to wonder
whether this may be because the man pages are not installed... could
this be? man man should work, right?)
I agree that a lot of this frustration is more because it is unknown
and different than what I am used to. But I think this will be the
case for a lot of users which come from Linux, and if Solaris wants to
make these people change OS, this should be taken into account.
- the actual kernel is not very important from a user point of view I
think. What is important is the hardware support, and I am not sure to
what extent OpenSolaris is good at this. For example, I have an Acer
laptop with an embedded webcam. For Linux, there was reasonably
quickly a driver (gspca) available. I don't know if this would have
been the case with OpenSolaris. Of course, this also depends on the
size of the developer community and I think that's were Linux has a
plus.
As a developer, the kernel code of OpenSolaris seems much more
documented and organised than that of Linux, which is definitely a
plus.
If OpenSolaris can get these three points right, I believe it could be
a great alternative...
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
262
From:
Cardiff, Wales, United Kingdom
Registered:
5/2/06
|
|
|
|
Re: joining Sun
Posted:
Mar 22, 2007 7:19 AM
in response to: tdescham
|
|
On 22/03/07, Thomas De Schampheleire <patrickdepinguin at gmail dot com> wrote:
> - then there are the command line programs. There might be a good
> reason for this, but I feel that some of the Solaris-shipped tools are
> inferior to the GNU tools. For example, I don't see a reason why a
> simple recursive grep with 'grep -R' does not work on Solaris.
It doesn't on linux either (i think you mean 'grep -r'),
but yes - this drives me mad too :) You should have a /usr/sfw/bin/ggrep
that works how you want - if not, you need to add the 'SUNWggrp' package.
> Even 'man man' doesn't work here. (I'm beginning to wonder
> whether this may be because the man pages are not installed... could
> this be? man man should work, right?)
Either the man command or the manpages aren't installed on your box:
pkgadd -d /cdrom/Solaris_11/Product SUNWdoc SUNWman
catman -w
> - the actual kernel is not very important from a user point of view I
> think. What is important is the hardware support
A few years back you'd just check hardware worked with Linux before
buying it. If you're going to build a dedicated Solaris box, that's the best
plan (although the hardware compatibility list for sun needs some TLC).
--
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
77
From:
Registered:
1/21/07
|
|
|
|
Re: joining Sun
Posted:
Mar 22, 2007 8:04 AM
in response to: number9
|
|
On 3/22/07, **** Davies <rasputnik at gmail dot com> wrote:
> It doesn't on linux either (i think you mean 'grep -r'),
> but yes - this drives me mad too :) You should have a /usr/sfw/bin/ggrep
> that works how you want - if not, you need to add the 'SUNWggrp' package.
In my version of grep (2.5.1), -R and -r are the same. I use -R
because a lot of other tools, like ls, only support -R. ls -r means
'reverse'.
Another annoyance is that most tools do not accept --help. This is
common with GNU tools, and I prefer it over -h, because some tools
might use -h for a real thing. In case -h means "remove all files",
then you're screwed...
>
> > Even 'man man' doesn't work here. (I'm beginning to wonder
> > whether this may be because the man pages are not installed... could
> > this be? man man should work, right?)
>
> Either the man command or the manpages aren't installed on your box:
>
> pkgadd -d /cdrom/Solaris_11/Product SUNWdoc SUNWman
> catman -w
>
pkginfo SUNWman does show:
system SUNWman On-Line Manual Pages
doesn't this mean it is installed?
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: joining Sun
Posted:
Mar 22, 2007 11:13 AM
in response to: tdescham
|
|
>In my version of grep (2.5.1), -R and -r are the same. I use -R
>because a lot of other tools, like ls, only support -R. ls -r means
>'reverse'.
Tools like "grep" really should not have sprouted a "-R" because it
is contrary to the Unix tool philosophy. Gnu apparently wants to
reimplement all tools inside all other tools.
>Another annoyance is that most tools do not accept --help. This is
>common with GNU tools, and I prefer it over -h, because some tools
>might use -h for a real thing. In case -h means "remove all files",
>then you're screwed...
All our tools accept "man tool"; that's actually 3 letters less typing.
Casper
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,091
From:
CA
Registered:
4/27/05
|
|
|
|
Re: joining Sun
Posted:
Mar 22, 2007 11:49 AM
in response to: casper
|
|
On Thu, 22 Mar 2007, Casper.***@Sun.COM wrote:
> All our tools accept "man tool"; that's actually 3 letters less typing.
Indeed; and for a concise "Usage" message, "tool -?" often (if
not always) does the trick.
--
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 at opensolaris dot org
|
|
|
|
|
Posts:
3,398
From:
Registered:
3/9/05
|
|
|
|
Re: joining Sun
Posted:
Mar 22, 2007 12:34 PM
in response to: rich
|
|
>On Thu, 22 Mar 2007, Casper.***@Sun.COM wrote:
>
>> All our tools accept "man tool"; that's actually 3 letters less typing.
>
>Indeed; and for a concise "Usage" message, "tool -?" often (if
>not always) does the trick.
(I generally find the tool --help output unhelpful; it's generally
to terse and unstructured)
Casper
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,154
From:
US
Registered:
6/14/05
|
|
|
|
Re: joining Sun
Posted:
Mar 22, 2007 11:52 AM
in response to: tdescham
|
|
On 22/03/07, Thomas De Schampheleire <patrickdepinguin at gmail dot com> wrote:
> Another annoyance is that most tools do not accept --help. This is
> common with GNU tools, and I prefer it over -h, because some tools
> might use -h for a real thing. In case -h means "remove all files",
> then you're screwed...
That is a matter of preference. I always hated the -- options GNU
utilities use since they were so much more to type. I will admit
GNU/Linux systems get you used to typing "cmd --help" instead of "man
cmd" which I think is a bad habit. I think most people got used to
doing this since documentation is something that was usually
completely overlooked on most GNU/Linux distributions...
--
"Less is only more where more is no good." --Frank Lloyd Wright
Shawn Walker, Software and Systems Analyst
binarycrusader at gmail dot com - http://binarycrusader.blogspot.com/
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,091
From:
CA
Registered:
4/27/05
|
|
|
|
Re: joining Sun
Posted:
Mar 22, 2007 11:58 AM
in response to: swalker
|
|
On Thu, 22 Mar 2007, Shawn Walker wrote:
> That is a matter of preference. I always hated the -- options GNU
> utilities use since they were so much more to type. I will admit
You and me both!
--
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 at opensolaris dot org
|
|
|
|
|
Posts:
1,674
From:
Registered:
7/15/05
|
|
|
|
Re: joining Sun
Posted:
Mar 26, 2007 6:34 AM
in response to: rich
To: OpenSolaris » discuss
|
|
> On Thu, 22 Mar 2007, Shawn Walker wrote:
>
> > That is a matter of preference. I always hated the
> -- options GNU
> > utilities use since they were so much more to type.
> I will admit
>
> You and me both!
Add me to that list.
"--switch" is not the UNIX(R) way. It's inconsistent with the "-[a-zA-Z]" phylosophy, and consistency is one of the most important benefits and perks UNIX has to offer.
In other words, GNU phylosophy *detracts* from user's efficiency at the expense of "readability" and "choice".
I argue however, that breaking consistency is far worse.
It's like walking around the corner only to get one's face smashed full force by someone's fist.
|
|
|
|
|
Posts:
1,091
From:
CA
Registered:
4/27/05
|
|
|
|
Re: Re: joining Sun
Posted:
Mar 26, 2007 9:31 AM
in response to: ux-admin
|
|
On Mon, 26 Mar 2007, UNIX admin wrote:
> Add me to that list.
>
> "--switch" is not the UNIX(R) way. It's inconsistent with the
> "-[a-zA-Z]" phylosophy, and consistency is one of the most important
> benefits and perks UNIX has to offer.
Another thing that I find almost annoying is the use of "-switch"
(find(1) and dd(1M) are the most obvious examples that come to mind).
Should that be read as "-switch" or "-s -w -i -t -c -h"? POSIX
(and I) say the latter.
--
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 at opensolaris dot org
|
|
|
|
|
Posts:
1,674
From:
Registered:
7/15/05
|
|
|
|
Re: Re: joining Sun
Posted:
Mar 26, 2007 10:06 AM
in response to: rich
To: OpenSolaris » discuss
|
|
> Another thing that I find almost annoying is the use
> of "-switch"
> (find(1) and dd(1M) are the most obvious examples
> that come to mind).
> Should that be read as "-switch" or "-s -w -i -t -c
> -h"? POSIX
> (and I) say the latter.
And I would agree with both you and POSIX. "-switch" would be "-s -w -i -t -c -h" to me.
As in:
df -hF zfs
|
|
|
|
|
Posts:
1,674
From:
Registered:
7/15/05
|
|
|
|
Re: joining Sun
Posted:
Mar 26, 2007 6:38 AM
in response to: swalker
To: OpenSolaris » discuss
|
|
> I will admit GNU/Linux systems get you used to typing "cmd --help"
> instead of "man
> cmd" which I think is a bad habit. I think most
> people got used to
> doing this since documentation is something that was
> usually
> completely overlooked on most GNU/Linux
> distributions...
...Or in plain English: people were too lazy to crank out man pages, i.e. when quantity ("just release it, it works for me") matters over quality ("either do it right and completely, or don't do it at all").
|
|
|
|
|
Posts:
262
From:
Cardiff, Wales, United Kingdom
Registered:
5/2/06
|
|
|
|
Re: joining Sun
Posted:
Mar 22, 2007 12:49 PM
in response to: tdescham
|
|
On 22/03/07, Thomas De Schampheleire <patrickdepinguin at gmail dot com> wrote:
> pkginfo SUNWman does show:
> system SUNWman On-Line Manual Pages
>
> doesn't this mean it is installed?
That's the man command, not the man pages.
--
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,793
From:
GB
Registered:
3/9/05
|
|
|
|
Re: joining Sun
Posted:
Mar 22, 2007 12:58 PM
in response to: number9
|
|
**** Davies wrote:
> On 22/03/07, Thomas De Schampheleire <patrickdepinguin at gmail dot com> wrote:
>
>> pkginfo SUNWman does show:
>> system SUNWman On-Line Manual Pages
>>
>> doesn't this mean it is installed?
>
> That's the man command, not the man pages.
The SUNWman package contains the man pages for the ON consolidation,
other consolidations deliver their man pages in other packages.
The /usr/bin/man command is delivered in the SUNWdoc package.
--
Darren J Moffat
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
262
From:
Cardiff, Wales, United Kingdom
Registered:
5/2/06
|
|
|
|
Re: joining Sun
Posted:
Mar 23, 2007 3:17 AM
in response to: darrenm
|
|
On 22/03/07, Darren J Moffat <Darren dot Moffat at sun dot com> wrote:
> **** Davies wrote:
> > On 22/03/07, Thomas De Schampheleire <patrickdepinguin at gmail dot com> wrote:
> >
> >> pkginfo SUNWman does show:
> >> system SUNWman On-Line Manual Pages
> >>
> >> doesn't this mean it is installed?
> >
> > That's the man command, not the man pages.
>
> The SUNWman package contains the man pages for the ON consolidation,
> other consolidations deliver their man pages in other packages.
>
> The /usr/bin/man command is delivered in the SUNWdoc package.
Ok, ok, got it back-asswards - "you need both" is what I was trying to say :)
--
Rasputin :: Jack of All Trades - Master of Nuns
http://number9.hellooperator.net/
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,154
From:
US
Registered:
6/14/05
|
|
|
|
Re: joining Sun
Posted:
Mar 22, 2007 11:50 AM
in response to: tdescham
|
|
On 22/03/07, Thomas De Schampheleire <patrickdepinguin at gmail dot com> wrote:
> What I personally find important in Linux is:
> - the user experience, mostly embodied by the KDE desktop environment.
> I don't like Gnome, so I don't like the default Solaris desktop
> environment. I heard that there is a KDE project for OpenSolaris, so
> that is great. If most of the GUI programs would run on OpenSolaris as
> well, then the biggest challenge has been overwon I think.
The challenge has been essentially met then, I believe. KDE was on
Solaris a few years ago thanks to the stoic efforts of Stefan Teleman
and others (see http://solaris.kde.org/).
I would never expect sun to ship KDE in the main distribution though
or as a default. On the "companion software" CD or something like
that, sure...
> - then there are the command line programs. There might be a good
> reason for this, but I feel that some of the Solaris-shipped tools are
> inferior to the GNU tools. For example, I don't see a reason why a
> simple recursive grep with 'grep -R' does not work on Solaris. Why
Because -R doesn't fit with the UNIX philosphy. It fits with the GNU
philosophy. Remember, GNU stands for "GNU's NOT UNIX" :)
> there are two greps is something I do not understand either.
> I do not get the way man works either. On Linux, you would just do
> "man cat" or "man vi", and it would just give you the correct man
> page. Even 'man man' doesn't work here. (I'm beginning to wonder
> whether this may be because the man pages are not installed... could
> this be? man man should work, right?)
Your manpath probably isn't set correctly. The default manpath for
Solaris does *not* include all of the man directories for all
installed software; it is up to you set it appropriately.
Setting your manpath to include /usr/sfw/man, /opt/SUNWspro/man, etc.
would probably alleviate most of these. As far as I know, Sun requires
a man page for almost every binary, even if the software is 3rd party.
--
"Less is only more where more is no good." --Frank Lloyd Wright
Shawn Walker, Software and Systems Analyst
binarycrusader at gmail dot com - http://binarycrusader.blogspot.com/
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss at opensolaris dot org
|
|
|
|
|
| |
