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 this
Alan Coopersmith alan.coopersm...@sun.com 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?
Alan Coopersmith alan.coopersm...@sun.com 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
Joerg Schilling wrote:
Alan Coopersmith alan.coopersm...@sun.com 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
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
* 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
i
Joseph Mocker m...@sun.com 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
Volker A. Brandt v...@bb-c.de 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
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
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 generally
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:
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.
I
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.
--
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
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.
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
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
..
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 sysadmin was:
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
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
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
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
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 company
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
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
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
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
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:
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
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:
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
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
Shawn Walker swal...@opensolaris.org wrote:
Joerg Schilling wrote:
UNIX admin tripivc...@hotmail.com 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
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.
Alan Coopersmith alan.coopersm...@sun.com 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
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?
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
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
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:
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
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:
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
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 writing
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.
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
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
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
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
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.
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
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
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
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
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
On Wed, Dec 16, 2009 at 11:09 PM, UNIX admin tripivc...@hotmail.com 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
On Wed, Dec 16, 2009 at 11:24 PM, UNIX admin tripivc...@hotmail.com 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
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
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
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.
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 justification
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
python with
@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 mistakes: Implementing IPS in Python, and
ditching scripting capability in the packages. I'm sure these seemed
I continue to see
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 in
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 be
Hi Uros!
I really do not see need for Python, Perl and other scripting languagesto
be placed in SunOS. I believe that SUN has to buy Design Patternsand
Refactoring to patterns books along with The art of computer scienceand
share to their developers to continue developing perfect such
: 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 languagesto
be placed in SunOS. I believe that SUN has to buy Design Patternsand
Refactoring to patterns books along with The art
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
not saying
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,
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, what
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
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
build 114.
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 fine,
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.
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
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
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
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
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,
UNIX admin tripivc...@hotmail.com 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
--
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
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 consistently and repeatably
create databases via
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. Although,
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, but not
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.
2.
UNIX admin tripivc...@hotmail.com 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
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
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 workload
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
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 tries
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
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
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
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.
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
OpenSolaris, at least according to David Comay Co., is going for
Linux / GNU crowd directly, hence the forced-at-all-and-any-cost
replacement of System V utilities to GNU userland
Actually, that's never been stated as a goal in any form. What has
been said is there is a large community of
Like I said above, my local understanding about
David's comment is that
he meant OpenSolaris is a Linux replacement /for the
LAMPS niche/ .
Once again, OpenSolaris is about creating a superior
OS for targeted
niches, of which LAMPS is one. To win in such
niches, you do need to
I suspect he's a holdover from the switch from SunOS
to Solaris, way
back in the early 90s. SunOS was a BSD-based system,
and many
old-timers really disliked the switch to the
SVR4-based Solaris.
My first Solaris was 2.5.1. So I started off on a System V Release 4.0 UNIX,
and I feel
On 11/12/2009, at 1:26 PM, UNIX admin wrote:
There is indeed a failure here, and it's one of
communication: Sun
certainly needs to be clearer about exactly what
OpenSolaris is
targeting, and how it is going to get there. _I_
certainly could use
better information. And, yes, I do wish it
UNIX admin wrote:
OpenSolaris will never make it to the top of the food chain because it has
severe architectural issues, starting with the software management subsystem,
continuing with breaking compatibility with Solaris, and causing tremendous
engineering and software development effort
1 - 100 of 127 matches
Mail list logo
