Volker A. Brandt wrote:
> Upon rereading it, however, it seems to me that the thread reflects
> a deeply rooted frustration in a part of the user/developer community.
> Resorting to flames in a mailing list discussion is obviously not the
> best way to overcome this frustration. :-)
Especially si
Alan Burlison writes:
> Alan Coopersmith wrote:
>
> > Please take your insults of the members of this community elsewhere.
> > They are not welcome here.
>
> I've already issued a warning earlier today, that seems to have been
> ignored.
I agree with the two Alans in that the tone of postings in t
* Brian Wilson (bfwil...@doit.wisc.edu) wrote:
> A question for the group on one of these that has been answered, but
> I'm wondering if there's another valid answer -
>
> >I wanted to try virtualization with VirtualBox.
> >.
> >2. What about LVM and ext2,3,4 Support? I t would look better if
A question for the group on one of these that has been answered, but
I'm wondering if there's another valid answer -
I wanted to try virtualization with VirtualBox.
.
2. What about LVM and ext2,3,4 Support? I t would look better if i
could use my old linux storage discs by just plugging
Joerg Schilling wrote:
Alan Coopersmith wrote:
Craig S. Bell wrote:
I can't see vendors updating all of their software, though -- we still install
S8-built commercial packages today, and they have actions. The vendor doesn't
care to update them. Will they spend the effort for pkg? It's a
Alan Coopersmith wrote:
> Did providing SunOS 4 binary compatibility slow the adoption of
> providing Solaris 2 native binaries? (I don't know - it was before
> my time - I suspect it's just part of the cost of providing
> compatibility.)
If there was a working compatibility environment for Su
Alan Coopersmith wrote:
> Craig S. Bell wrote:
> > I can't see vendors updating all of their software, though -- we still
> > install S8-built commercial packages today, and they have actions. The
> > vendor doesn't care to update them. Will they spend the effort for pkg?
> > It's a potenti
Shawn Walker wrote:
Craig S. Bell wrote:
Let me play devil's advocate: If people have the option to continue
using the old package system (with it's action scripting
capabilities), then could that slow adoption of the new pkg format?
Or is that just the cost of providing compatibility?
I th
Craig S. Bell wrote:
Let me play devil's advocate: If people have the option to continue using the
old package system (with it's action scripting capabilities), then could that
slow adoption of the new pkg format? Or is that just the cost of providing
compatibility?
I think those users will
Craig S. Bell wrote:
> Alan, what will happen with old-style packages with dependencies on other
> SUNW* packages -- will there a way to artificially fulfill these? It seems
> like it will take some ongoing effort to continue supporting the SysV format.
IPS currently puts entries into the SVR4
Craig S. Bell wrote:
Alan, what will happen with old-style packages with dependencies on other SUNW*
packages -- will there a way to artificially fulfill these? It seems like it
will take some ongoing effort to continue supporting the SysV format.
IPS packages can provide what is called a "l
Alan, what will happen with old-style packages with dependencies on other SUNW*
packages -- will there a way to artificially fulfill these? It seems like it
will take some ongoing effort to continue supporting the SysV format.
Let me play devil's advocate: If people have the option to continue
Craig S. Bell wrote:
Shawn, thanks for explaining. I think that we'll get to where we need to be
for our enterprise build and recovery model. So much of what we do (especially
patching) is a big work-around, if you step back and take a look at it.
This amount of change naturally makes an ent
Shawn, thanks for explaining. I think that we'll get to where we need to be
for our enterprise build and recovery model. So much of what we do (especially
patching) is a big work-around, if you step back and take a look at it.
This amount of change naturally makes an entrenched sysadmin like m
Craig S. Bell wrote:
Shawn, this sounds promising. Just to be clear, will I be able to analyze and apply arbitrary updates while offline, or only well-known releases?
As far as repository ISO images, at this point, I only know of the major
releases found in the /release repository being suppo
Shawn, this sounds promising. Just to be clear, will I be able to analyze and
apply arbitrary updates while offline, or only well-known releases?
For instance, we use pca's proxy feature to cache our patches. So long as I
have a reference xref handy, pca can do all of the needed analysis offl
Craig S. Bell wrote:
> I can't see vendors updating all of their software, though -- we still
> install S8-built commercial packages today, and they have actions. The
> vendor doesn't care to update them. Will they spend the effort for pkg?
> It's a potential barrier.
That's why pkgadd & com
Craig S. Bell wrote:
I need to keep one local cached repository of updates for installing on a
private network (no internet needed during updates). I'm not clear on whether
the pkg tools fully support proxies yet. IMHO this is necessary for enterprise
usage.
This should be true as of build
My thoughts on migrating to the new world of install and update:
wanboot and flash archives (or their equivalent) are very important for
managing our site. I have been assured that a flar equivalent is coming for the
new tools, but that's all I know so far. We live and die by flar, this
functi
a b wrote:
"Never compromise", goes the wisdom at TOYOTA; lest any doubt that wisdom, they
are the undisputed ruler of the automotive industry, on this entire planet.
There is a lesson to be learned from that.
Actually see this week's Economist magazine (Dec 12th) - Toyota is not
the same for
I wouldn't argue that it's easier to maintain code in a dynamic high-
level language like Python rather a compiled relatively low-level
language like C. Some projects benefit from focus on elements of
programming like memory management and are thus better written in C,
but the problem that's
..
>> There is a lesson to be learned from that.
>>
>> And, what you ended up with, above, is a SALAD of half-C, half Python.
>> Perhaps you like curdled milk; I can't stand it.
>>
>> One of the first hardcore lessons I had been taught, when I was young and
>> starting my career as a sysadmi
Joseph Mocker wrote:
While I don't entirely agree with UNIX admin, I am sort of concerned
with the growing number of scripting environments that are now required
to make [Open]Solaris run.
First I realized that Perl was needed was when I discovered the kstat
was rewritten in Perl, which kind
Alan Coopersmith wrote:
Please take your insults of the members of this community elsewhere.
They are not welcome here.
I've already issued a warning earlier today, that seems to have been
ignored.
If the OGB feels it is necessary to suspend the individuals who have
been making offensive r
> Please take your insults of the members of this community elsewhere.
> They are not welcome here.
It's not meant as an insult; I'm merely stating the current state of affairs.
But if you'd like me to leave, I've no problem with that. Bye.
> I would think that by keeping state somewhere, either via SMF properties
> or something else, you can record that you've "initialized" your package
> already and so in the SMF methods you would check the state before
> performing any action.
I was thinking the same thing. However, several q
a b wrote:
>> It seems that the type of engineer at Sun did change since the days of
> Bill Joy.
>
> It certainly appears so.
> And it also does not look like the change was for the better.
Please take your insults of the members of this community elsewhere.
They are not welcome here.
--
> As many recent studies have shown, interpreted languages can bring
> identical or acceptable performance levels for many operations when
> suitable algorithms are employed.
I believe that Wikipedia would term the above paragraph as "weasel words",
and put the applicable notice on the article.
> Most ISVs won't support short term releases of OpenSolaris, and that
> really isn't on our radar.
You told me everything I need to know, thank-you-very-much. Goodbye.
_
Windows Live: F
> You find optimizing Python with C as "Proof enough"? An unfortunate
> statement of ignorance (meant literally, not as an insult).
None taken; if I need to be educated, then educate me.
> The time from development to deployment with Python is generally very low and
> the code is also general
> It seems that the type of engineer at Sun did change since the days of Bill
> Joy.
It certainly appears so.
And it also does not look like the change was for the better.
_
Windows Live Ho
"Volker A. Brandt" wrote:
> I understand your frustration, as I have been feeling it myself.
>
> Yes, Sun has made two big mistakes: Implementing IPS in Python, and
> ditching scripting capability in the packages. I'm sure these seemed
> like good engineering decisions way back at the drawing b
Joseph Mocker wrote:
> While I don't entirely agree with UNIX admin, I am sort of concerned
> with the growing number of scripting environments that are now required
> to make [Open]Solaris run.
>
> First I realized that Perl was needed was when I discovered the kstat
> was rewritten in Perl,
While I don't entirely agree with UNIX admin, I am sort of concerned
with the growing number of scripting environments that are now required
to make [Open]Solaris run.
First I realized that Perl was needed was when I discovered the kstat
was rewritten in Perl, which kind of bummed my Operation
On Wed, Dec 16, 2009 at 11:24 PM, UNIX admin wrote:
> > Significant portion of softwares in use at large
> > software installations
> > for high-traffic providers such as Google are written
> > in Python.
>
> Something else just occurred to me: since Google does it, why don't we go
> and tell the
On Wed, Dec 16, 2009 at 11:09 PM, UNIX admin wrote:
> > What would the benefit of that be?
>
> The target audience, which is sysadmins and system engineers, is familiar
> with C, and the project stands to benefit from that expertise.
>
> Not to mention that C will give you maximum performance, sh
On 17/12/2009, at 11:33 AM, UNIX admin wrote:
Welcome to a meritocracy. Those that do the work get
to make the
decisions as they've earned the right to do so.
In this, you are correct. But I also believe that you are in for a
surprise:
we will see what the acceptance rate of your decisio
On 17/12/2009, at 11:48 AM, a b wrote:
> To the customers who are paying you for new versions. Isn't that
where you'd
> send the bill for adding support for other new features in new OS
releases?
...Except that nobody is paying me, and is not going to pay me in
the foreseeable
future to
> Interest and acceptance of the OpenSolaris 200x releases has been quite
> high as should be obvious from the growth of the community since its
> release and the traffic stats that can be viewed from pkg.opensolaris.org.
They sure have, and I'm pretty certain it's from the end users, not from
a b wrote:
Under these circumstances, how does the OpenSolaris project expect to garner
ISV support?
Has anybody given any thought to this, what impact these IPS technical
decisions
will have on garnering ISV support? And what was their conclusion, and
what was
it based on?
How many ISVs cur
> To the customers who are paying you for new versions. Isn't that where you'd
> send the bill for adding support for other new features in new OS releases?
...Except that nobody is paying me, and is not going to pay me in the
foreseeable
future to deliver my product for OpenSolaris.
So basic
UNIX admin wrote:
Welcome to a meritocracy. Those that do the work get
to make the
decisions as they've earned the right to do so.
In this, you are correct. But I also believe that you are in for a surprise:
we will see what the acceptance rate of your decisions and your product will be.
An
UNIX admin wrote:
The viability
and growth of a tool's community is important when
considering choice of
development tools and language.
What are you saying?
When you choose a development tool (or programming language), it is
useful to know its general viability. That is, how vibrant and w
> Welcome to a meritocracy. Those that do the work get
> to make the
> decisions as they've earned the right to do so.
In this, you are correct. But I also believe that you are in for a surprise:
we will see what the acceptance rate of your decisions and your product will be.
And also, we will
> The viability
> and growth of a tool's community is important when
> considering choice of
> development tools and language.
What are you saying?
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@op
> Significant portion of softwares in use at large
> software installations
> for high-traffic providers such as Google are written
> in Python.
Something else just occurred to me: since Google does it, why don't we go and
tell the ZFS team to ditch C, and simply migrate it all to Python?
If Go
UNIX admin wrote:
Significant portion of softwares in use at large
software installations
for high-traffic providers such as Google are written
in Python.
So what?
Let me get this straight: just because Google does something, XYZ should also
do that something?
You mean, like "ME TOOs" that
> Significant portion of softwares in use at large
> software installations
> for high-traffic providers such as Google are written
> in Python.
So what?
Let me get this straight: just because Google does something, XYZ should also
do that something?
You mean, like "ME TOOs" that I've been writ
UNIX admin wrote:
What would the benefit of that be?
The target audience, which is sysadmins and system engineers, is familiar with
C, and the project stands to benefit from that expertise.
Not to mention that C will give you maximum performance, short of writing IPS
in assembler.
The fact
> What would the benefit of that be?
The target audience, which is sysadmins and system engineers, is familiar with
C, and the project stands to benefit from that expertise.
Not to mention that C will give you maximum performance, short of writing IPS
in assembler.
The fact that some portions
UNIX admin wrote:
> How about migrating the Python code to C?
What would the benefit of that be? There's already C code for the portions
of IPS where that is beneficial - and those portions change over time as needed,
but forcing a mass rewrite to a new language "just because" seems hardly
worth
UNIX admin wrote:
> No we won't, because this is costing money. Where can I send the bill,
> please?
To the customers who are paying you for new versions. Isn't that where you'd
send the bill for adding support for other new features in new OS releases?
--
-Alan Coopersmith-
UNIX admin wrote:
Then you'll have to re-create your package.
If I put the work, which was normally done in postinstall, postremove,
preinstall and preremove into SMF, how can I ensure that the sysadmin doesn't
accidentally enable package's SMF method which does the equivalent of preremo
> But Sun has always been engineering rather than
> marketing driven, and
> frankly, that's why I like them. :-)
When they were engineering driven, I was their biggest fan. But that has not
been the case for at least six years now, and possibly longer.
Now they are just marketing driven, and Sun
UNIX admin wrote:
Then you'll have to re-create your package.
If I put the work, which was normally done in postinstall, postremove,
preinstall and preremove into SMF, how can I ensure that the sysadmin doesn't
accidentally enable package's SMF method which does the equivalent of preremove
o
> Then you'll have to re-create your package.
If I put the work, which was normally done in postinstall, postremove,
preinstall and preremove into SMF, how can I ensure that the sysadmin doesn't
accidentally enable package's SMF method which does the equivalent of preremove
or postremove?
> Th
Alan Coopersmith wrote:
> Joerg Schilling wrote:
> > BTW: RFE 5007466 was closed, does this mean that star is now included in
> > Solaris?
>
> No, according to the bug database, it was closed due to lack of interest,
> since no one from the community responded to the mail the responsible
> manag
Joerg Schilling wrote:
> BTW: RFE 5007466 was closed, does this mean that star is now included in
> Solaris?
No, according to the bug database, it was closed due to lack of interest,
since no one from the community responded to the mail the responsible
manager sent trying to propose a way forward
Shawn Walker wrote:
> Joerg Schilling wrote:
> > UNIX admin wrote:
> >
> >> How many Juergen Keils and Masayuki Murayamas are out there in the
> >> community?
> >
> > There are more but Sun does not yet have the collaboration infrastructure
> > to
> > get them involved, people are even disc
Volker A. Brandt wrote:
...
But this is all water under the bridge. I would like to see a sample
package that delivers an SMF service that does some arbitrary post-install
task (like configuring and starting Sybase :-) and then removes the
SMF service from the system. That's what people need,
Volker A. Brandt wrote:
> Alan Coopersmith writes:
>> Volker A. Brandt wrote:
>>> However, there is also the fact that Sun had already committed to
>>> a scripting language, Perl. There was a statement that Perl was a core
>>> part of Solaris and would always be present on the miniroot. (I am
>>
on, 14 Dec 2009 19:10:59 +0100
> To: ur...@live.com
> CC: opensolaris-discuss@opensolaris.org
> Subject: Re: [osol-discuss] Some Why?-Questions
>
> Hi Uros!
>
>
> > I really do not see need for Python, Perl and other "scripting languages"to
> > be pl
Hi Uros!
> I really do not see need for Python, Perl and other "scripting languages"to
> be placed in SunOS. I believe that SUN has to buy "Design Patterns"and
> "Refactoring to patterns" books along with "The art of computer science"and
> share to their developers to continue developing perfect
Alan Coopersmith writes:
> Volker A. Brandt wrote:
> > However, there is also the fact that Sun had already committed to
> > a scripting language, Perl. There was a statement that Perl was a core
> > part of Solaris and would always be present on the miniroot. (I am
> > not saying that Perl would
UNIX admin wrote:
> Because if we want to be ready for the future, we must now maintain two sets
> of packages for every component - one for the enterprise, which is what feeds
> us and pays the bills, one for being ready for the future.
And if it wasn't IPS, then it would be some other feature
coopersm...@sun.com
> To: v...@bb-c.de
> CC: opensolaris-discuss@opensolaris.org
> Subject: Re: [osol-discuss] Some Why?-Questions
>
> Volker A. Brandt wrote:
> > Shawn Walker writes:
> >> Volker A. Brandt wrote:
> >>> Yes, Sun has made two big mistake
Volker A. Brandt wrote:
> Shawn Walker writes:
>> Volker A. Brandt wrote:
>>> Yes, Sun has made two big mistakes: Implementing IPS in Python, and
>>> ditching scripting capability in the packages. I'm sure these seemed
>> I continue to see assertions that pkg(5) should not have been written in
>>
Shawn Walker writes:
> Volker A. Brandt wrote:
> > Yes, Sun has made two big mistakes: Implementing IPS in Python, and
> > ditching scripting capability in the packages. I'm sure these seemed
>
> I continue to see assertions that pkg(5) should not have been written in
> python with little justifi
Volker A. Brandt wrote:
Yes, Sun has made two big mistakes: Implementing IPS in Python, and
ditching scripting capability in the packages. I'm sure these seemed
I continue to see assertions that pkg(5) should not have been written in
python with little justification for this claim.
Signifi
> > You're getting to see the process from the
> > slaughterhouse through the kitchen,
> > instead of just getting the steak delivered on a
> > plate when it's fully cooked
> > like you did before - it's going to be messy, but
> > hopefully we'll end up with
> > a better product in the end.
>
> And
pkg(5) seems to use a set of actions to define what and how to do
things, and they seem to be similar to plugins in that you just drop
the action file in a directory and things work.
check http://opensolaris.org/sc/src/pkg/gate/src/modules/actions/
does the plugin list get updated every action that
UNIX admin wrote:
The full list of publication tools are:
pkgdepend(1)
pkgdiff(1) -- build 130+
pkgmogrify(1)
pkgrecv(1)
pkgsend(1)
Please note that pkgsend will allow you to import an
existing SVR4
package (minus class action scripts), directory, or
tarball as the basis
for a new package. T
> You're getting to see the process from the
> slaughterhouse through the kitchen,
> instead of just getting the steak delivered on a
> plate when it's fully cooked
> like you did before - it's going to be messy, but
> hopefully we'll end up with
> a better product in the end.
And that's perfectly
> See "man pkgsend.1", specifically the "generate"
> subcommand, in builds
> 118 or later. Although I'd strongly recommend build
> 129 or later due to
> the significant improvements that have been made
> since then.
So, that explains a whole lot. Last time I studied this technology was at
bui
UNIX admin wrote:
If preremove, postremove, postinstall and preinstall scripts aren't allowed/possible, what exactly
gets "imported" / "pulblished" if the SVR4 has no physical payload except to do
all the work with the pre and post scripts?
The name of the package and maybe one or two other b
> Here you go.
Thanks.
> These docs should tell you ALMOST
> everything you want to know
> about IPS-style packaging versus the SVR4 packaging
> method. You can also
> do direct SVR4 publishing to an IPS repo.
If preremove, postremove, postinstall and preinstall scripts aren't
allowed/possible,
Here you go. These docs should tell you ALMOST everything you want to know
about IPS-style packaging versus the SVR4 packaging method. You can also
do direct SVR4 publishing to an IPS repo.
http://wikis.sun.com/display/OpenSolarisInfo200906/Deploying+Your+Application
~ Ken Mays
--- On Sat, 12/1
UNIX admin wrote:
If you want to bundle packages together,
We do not understand each other.
In order to create a SVR4 package, a prototype(4) file must be created, which
declares permissions and file attributes in a package, and specifies inclusion
of metadata, such as depend(4), and pkginfo
> If you want to bundle packages together,
We do not understand each other.
In order to create a SVR4 package, a prototype(4) file must be created, which
declares permissions and file attributes in a package, and specifies inclusion
of metadata, such as depend(4), and pkginfo(4). In other words
Banks aren't really hung up on whether its Solaris 10 or the future Solaris
X based upon OpenSolaris. They care that it is a robust, stable and
supported product that will do what they need for the right price. I do not
doubt at all that Sun will be doing that With Solaris.Next.
Comparing the curr
UNIX admin wrote:
That isn't true. There are many tools that are
available with IPS to
create and publish packages.
And which tool generates the bundle(4) file?
If you want to bundle packages together, at the moment, you publish them
all to the same repository. The repository can then be
> There is significant end-user documentation, so I'll
> assume you're
> referring to publication documentation.
And this time, you will be assuming correctly.
> That isn't true. There are many tools that are
> available with IPS to
> create and publish packages.
And which tool generates the
UNIX admin wrote:
The biggest pain with IPS right now is very poor and lacking documentation, and
inability to run pre and postinstall scripts, instead of forcing the ABUSE of
SMF.
There is significant end-user documentation, so I'll assume you're
referring to publication documentation.
Pu
> See man pkgsend.1
And which tool generates the bundle(4) file?
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
> you do not think the current state of the patching
> system in solaris
> is just broken at the moment?
Never had a problem with it, because the management system I employ works
completely differently.
In my system, patches are never applied to production systems, but to the
operating system b
you do not think the current state of the patching system in solaris
is just broken at the moment?
I feel your pain though, and i mostly agree with what you say. but i
think IPS can be improved to a point where it makes my and your life
easier.
On Fri, Dec 11, 2009 at 4:30 PM, UNIX admin wrote:
>
> From talking to both Solaris sysadmins and Linux
> users that like to change, it
> seems that the "indiana way" is not expected/wanted
> from either party.
That's what gets me in this whole circus, something is being decided for us,
and we're told it's good for us, but in the end the product t
UNIX admin wrote:
For instance, what is the equivalent of pkgmk(1) for IPS?
See man pkgsend.1
Cheers,
--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
> But the next release of Solaris will use the new
> packaging systems and
> installers, so SXCE is farther from Solaris 11 than
> OpenSolaris is.
And that also was my point:
because IPS is so radically different than SVR4 package format, whoever made
these decisions just caused us double worklo
McDonald, Kyle wrote:
So if a package isn't the way to do it, how about an alternative? How would you
suggest that an ISV reliably ship a preconfigured database?
Provide a setup or configuration tool that performs the necessary steps?
Make it part of an SMF service?
The issue at hand here is
Joerg Schilling wrote:
UNIX admin wrote:
How many Juergen Keils and Masayuki Murayamas are out there in the community?
There are more but Sun does not yet have the collaboration infrastructure to
get them involved, people are even discouraged by the current situation.
The necessary framew
UNIX admin wrote:
> Agreed, and you're right. Perhaps you might answer me this:
>
> 1. SX:CE, the closest one has ever come to Solaris 11, is being killed
The problem is that there was no discussion on how Solaris should be extended.
>From talking to both Solaris sysadmins and Linux users that l
UNIX admin wrote:
> Agreed, and you're right. Perhaps you might answer me this:
>
> 1. SX:CE, the closest one has ever come to Solaris 11, is being killed
But the next release of Solaris will use the new packaging systems and
installers, so SXCE is farther from Solaris 11 than OpenSolaris is.
>
> Banks should continue to use Solaris 10 *for now* for
> their database servers
> and mission critical systems - OpenSolaris releases,
> like Solaris Express
> releases before it, are previews of the next
> enterprise release of Solaris -
> they're works in progress, good enough for many
> tasks,
> UNIX admin wrote:
> > I guess I failed to make my point - you can't engineer
> an enterprise piece of software, for example for a bank or
> an insurance agency, or the any Fortune 100 company, then
> come to the sales presentation and tell them that they must
> use OpenSolaris.
Great point. Alth
UNIX admin
Cc: opensolaris-discuss@opensolaris.org
Subject: Re: [osol-discuss] Some Why?-Questions
UNIX admin wrote:
>> The better question is why someone is doing something
>> so broken in the
>> first place.
>
> There is nothing broken about being able to consiste
> But there is something broken about abusing the
> package installation
> process to setup something as complex as a database
> in my view.
You go ahead and tell that to all those banks which run world's trading &
exchange systems, and all those insurance companies, and the military. Tell
them
UNIX admin wrote:
> How many Juergen Keils and Masayuki Murayamas are out there in the community?
There are more but Sun does not yet have the collaboration infrastructure to
get them involved, people are even discouraged by the current situation.
Jörg
--
EMail:jo...@schily.isdn.cs.tu-berli
UNIX admin wrote:
The better question is why someone is doing something
so broken in the
first place.
There is nothing broken about being able to consistently and repeatably create
databases via packages.
But there is something broken about abusing the package installation
process to setup
> The better question is why someone is doing something
> so broken in the
> first place.
There is nothing broken about being able to consistently and repeatably create
databases via packages.
--
This message posted from opensolaris.org
___
opensolari
1 - 100 of 139 matches
Mail list logo
