subject:"\[osol\-discuss\] Some Why\?\-Questions"


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 slowly want to move to the newer package 
system.  IPS provides a lot of additional functionality not found in 
SVR4 (to my knowledge):


* remote search

* advanced query syntax (can search for packages with specific 
dependencies, etc.)


* ZFS integration (image-update; alternate boot environments)

* handles package renames, obsoletes

* multi-variant packages (one package for SPARC/x86)

* a full set of publication tools

* full network repository support

* a web interface for package repositories, complete with search and 
"one-click install" capability


* a graphical package manager (i don't cound prodreg or smc :P)

* support for ssl-authentication based repository access

* the ability to provide your own source for packages that won't 
automatically be overridden during upgrades, and to control the exact 
priority of software sources when installing software and dependencies


* massive performance improvements for system upgrade scenarios

* only downloads differences between package versions when updating 
installed packages


* eliminates the need for patches :)

--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-17 Thread Alan Coopersmith

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 package database for the
packages installed via IPS that have information about the "legacy"
package they replaced, so that package dependencies can be satisfied.

> 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?

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.)

-- 
-Alan Coopersmith-   alan.coopersm...@sun.com
 Sun Microsystems, Inc. - X Window System Engineering

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


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 "legacy" action that allows 
them to declare themselves as providing specific SVR4 dependencies. 
This allows most SVR4 packages to install without issue since they 
believe their dependencies are already installed.


See "man pkg.5" for more information.

--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

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 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?

Thanks for your reply...  -cheers, CSB
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


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 entrenched sysadmin like me a bit 
apprehensive.  Even so, I freely admit there are many things about the current 
Solaris install and patch bits that I will gladly leave behind.  =-)

Towards that end, I'm glad that somebody, somewhere is throwing out the cruft 
and addressing those long-standing problems -- even if the solution is not 
optimized to fit into my comfort zone.  We just haven't seen the whole picture 
yet.  -c


Thanks.  It is my firm hope that nobody will miss PCA after using pkg(5).

--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

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 me a bit 
apprehensive.  Even so, I freely admit there are many things about the current 
Solaris install and patch bits that I will gladly leave behind.  =-)

Towards that end, I'm glad that somebody, somewhere is throwing out the cruft 
and addressing those long-standing problems -- even if the solution is not 
optimized to fit into my comfort zone.  We just haven't seen the whole picture 
yet.  -c
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

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 supported.

I don't know what the plan yet is to fully support the off-line case for
the /support or /dev repositories.

As for the webcache thing, yes, you should be able to perform installs
or updates completely "offline" assuming your proxy has cached all of
the package manifest, file, and catalog data.

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 offline. If
I already have all of the needed patches cached, then I don't need to go any
farther than my proxy host.

Once I've tested my golden update level, I want to repeat the same update
process on more hosts, with a minimum of internet needed (or none if possible).
Thanks again... -cheers, CSB

It is planned that some sort of download only option is added to
image-update and install. I believe it is also planned to enhance
updatemanager to be able to prepare for the update as well.

So even if you didn't have a proxy in place, you should eventually be
able to do something like:

pfexec pkg image-update --download-only

...and then later:

pfexec pkg image-update

...completely offline.

--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

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 offline.  If 
I already have all of the needed patches cached, then I don't need to go any 
farther than my proxy host.

Once I've tested my golden update level, I want to repeat the same update 
process on more hosts, with a minimum of internet needed (or none if possible). 
 Thanks again...  -cheers, CSB
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-17 Thread Alan Coopersmith

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 are still provided for installing existing
SVR4 packages.

-- 
-Alan Coopersmith-   alan.coopersm...@sun.com
 Sun Microsystems, Inc. - X Window System Engineering

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


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 128+.  With the exception that some 
requests can't be proxy-cached (such as remote search or the web 
interface or publication operations) since all of the content is dynamic.


The intention of the pkg(5) project is certainly to make it web-cache 
friendly (squid, et al.) as much as possible.


You also have the option of setting up a completely local copy of the 
package repository for major releases (such as 2009.06) using the 
repository ISO images that are provided.


Cheers,
--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

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 
function is a must-have.

I'm not partial as to which languages are used for pkg tools, so long as they 
perform.  It looks like these enhancements are underway.  I don't care how 
*many* languages you use, so long as the boot archive doesn't grow appreciably.

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.

I guess that retooling my own packages is inevitable.  There's a cost 
associated with it, but I'm not married to the old tools -- just very familiar 
with them.  I do like Jumpstart quite a bit for extracting flar's, it's simple. 
 No JET in use here.

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.

I think that the action-less design will make installation and updates more 
reliable.   Great, I will benefit from that.  Even so, I still need some way to 
take a few actions, I guess we just have to be a bit clever to make that happen.

I make my bread and butter on the old tools, but I look forward to seeing where 
the new tools take will us.  I can live in both worlds at the same time, so 
long as the decision-makers don't conclude that Solaris Next is too alien to 
adopt.

Thank you for reading...  -cheers, CSB
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-17 Thread Hugh McIntyre


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 force it was previously.  Certainly not the shining example in 
the motor industry any more.  They actually managed to lose more than GM 
in the first quarter of 2009, and are apparently finding that others 
have caught up in quality while producing less boring cars, and are 
therefore losing a bunch of money and need to find a turnaround plan.


As for the rest of the thread, I don't want to comment except to say 
that (as an outsider), it seems that the real unsolved issue is 
postinstall scripts and not really C as an implementation language.


Hugh.
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-17 Thread Bayard Bell

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 impacting the population of C programmers is  
that C is chiefly used in "close to the metal" code or things that  
need to run with a minimum of support from other OS facilities like  
kernels or SMF. Languages like Java have been made central to an  
approach to development that emphasises higher-level logic and more  
general problem solving. This has its ups and its downs, but the fact  
of the matter is that languages like perl, Python, and Ruby that can  
be used as much for scripting and automation as web development. That  
amounts to access to a much wider range of jobs, so people tend to  
have a loose ability to read C and at least a passable ability to  
write in a high-level language and a capability to climb the learning  
curve quite a lot faster learning another dynamic language rather  
learning C. This is reflected in education: from what I've seen of  
computer science programs in the US and UK, the move away from C to  
Java or C# as the first language taught in computer science courses  
and in many cases the only language learned in the classroom has been  
fairly firmly entrenched for more than 15 years. The emphasis has thus  
shifting towards code that expresses the logic of the problem you're  
trying to solve as opposed to the lower-level mechanics of the  
implementation.


Such is why perl and Python tend to be the integration glue that holds  
large-scale infrastructure together at places like Google: these sites  
use technologies which solve their problems and for which they can  
readily source talented people familiar with the technology. To the  
extent that there's a question of "hip" or "cool", it's just as fair  
to say that movement from mainframes to distributed systems or from  
terminal applications to client-server to n-tier partake of fashion  
phenomena: you can't completely extricate motion in marketplaces with  
so much money sloshing around from trendiness. You go on to mention  
Bill Joy, but these are also the kind of dynamics that led Joy to  
think that developers already versed in C might benefit from a Unix  
shell using C syntax rather than having to learn Bourne. Conversely,  
Joy found himself fifteen years later sufficiently convinced that C  
wasn't the be-all, end-all of language design or implementation that  
he helped mid-wife Java at Sun.


I don't therefore see it as inherently objectionable that something  
like packaging be written in Python. The upside of writing in a  
dynamic language is that you can read the code from any point where  
the documentation leaves off (e.g. internals), which can also make it  
easier to get not just bug reports but patches from the community. As  
far as performance goes, any well-designed packaging system is going  
to have most of the work done on its behalf by system calls when it  
comes time to lay down the software. The difference in execution time  
when evaluating metadata, which is the rest of what you'll need to do,  
is likely to be sufficiently comparable that no one's going to  
complain that their software install is intolerably slow. Performance  
optimisation past a certain point of adequacy becomes a trade-off  
between maintainable code and further performance benefits, which is  
why premature optimisation is said to be a fatal mistake in software  
engineering. Choosing the right language for a project can be a  
version of that dilemma.


Again, I'm not arguing that there are perfect languages (or that there  
haven't been some nasty side effects from dynamics that have resulted  
in a generation of developers who generally think that memory  
management is a magic property of the virtual machine running their  
code and don't understand much about how these classes of problems  
impact performance and scale, not to mention reinforcing unnecessarily  
short lifetimes for computers, as developers expect consumers to  
continue compensating for poor software engineering by buying systems  
with faster CPUs, more cores, and more memory to run it)–I think some  
of the benefits of higher-level languages can be overstated to support  
conclusion and that this has had some downsides in terms of software  
quality and development expertise. I don't think that's the case here.


Am 17 Dec 2009 um 09:50 schrieb Joerg Schilling:


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 of bummed my Operations folks out  
to
have to install Perl just for a few uti

Re: [osol-discuss] Some Why?-Questions

2009-12-17 Thread Chavdar Ivanov

..
>> 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:
>> 
>> CONSISTENCY is LAW.
>> 
>> "No matter what you do, be it right or wrong, good or bad, it needs to be 
>> consistent."
>> 
>> But this salad, half-this, half-that... that is no consistency.
>> It's a hacker's paradise, not something a true engineer can or would be 
>> proud of.
..

"A foolish consistency is the hobgoblin of little minds, adored by little 
statesmen and philosophers and divines."

Ralph Waldo Emerson

Cheers
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


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 of bummed my Operations folks out to 
have to install Perl just for a few utilities that had previously been 
written in C. (I ended up rewriting kstat for them in C, pretty easily).


I think you'll find that many of us would like to replace perl with 
python ;)  (And I say this as someone that spent many years writing 
perl/XS code until recently.)


...
Especially if you are getting performance by writing C modules for 
critical functions, it kind of reduces the "we've got to use scripting 
language X" argument.


I really can't agree with that sentiment.

As I mentioned in another reply, there are often times where lower-level 
langauge benefits are mostly irrelevant as you spend the majority of 
execution time simply waiting for user input, or waiting on I/O 
operations (disk or network) to complete.


If you can find a happy balance where a relatively small portion of your 
codebase is written in a lower-level language, but still achieve great 
performance overall for your application using a higher-level language, 
then I believe that the lowered costs of development both in time and 
other areas are of greater benefit than whatever might be achieved using 
a lower-level language.


--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-17 Thread Alan Burlison


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 remarks on this alias, please send a list of names 
to website-admin.


If we feel that individuals are violating the site TOU we reserve the 
right, as outlined in the TOU, to suspend people immediately, and with 
no further warning.


Thanks.

--
Alan Burlison
--

[1] http://hub.opensolaris.org/bin/view/Main/tou
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


> 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.
  
_
Keep your friends updated—even when you’re not signed in.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


> 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 questions remain in my mind:

how do I "signal" the SMF method that my package is being removed?

What about SMF overload? Every package would have to have a lingering method...
and I have hundreds of such packages; customers where I worked have thousands.

Can you imagine all those lingering methods in the output of svcs -a? They don't
do anything until package removal, but they have to be there. It'd be an SMF 
"overload".

It would be a mess. It's not an elegant solution.
  
_
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail 
you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-17 Thread Alan Coopersmith

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.

-- 
-Alan Coopersmith-   alan.coopersm...@sun.com
 Sun Microsystems, Inc. - X Window System Engineering

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


> 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 also happen to spend a lot of my time writing full, self-contained programs in
the AWK programming language. This language just so happens to be interpreted.

"AWK was born on a slow machine with a 4MHz CPU and 16KB of memory", wrote
Aho, Kernighan and Weinberger in their book on the language, so you can perhaps
imagine the speed of execution one can obtain from such a product on modern
systems whose processors have GigaHertz tact frequencies and hundreds of 
gigabytes
of memory, and indeed, the speed of execution of my programs is very great.

But when I use awka, the AWK to ANSI C compiler, and then use hp's or Sun's
compilers with optimizations, I regularly get 100% performance improvements,
sometimes more. Obviously, the algorithm is the same.

There is a lesson to be learned from that, too.
  
_
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail 
you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


> 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: Friends get your Flickr, Yelp, and Digg updates when they e-mail 
you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


> 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 very easy to maintain.  This hopefully means faster
> development with more stable, more maintainable, and less buggy software and 
> is the reason, I imagine, that it was chosen and accepted.  Performance is a 
> trade-off, but 
> with C-optimizations (Pythonic C libraries) the trade-off can be reduced 
> significantly where needed.

Now see here, to me, that is unacceptable.

"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.

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:

CONSISTENCY is LAW.

"No matter what you do, be it right or wrong, good or bad, it needs to be 
consistent."

But this salad, half-this, half-that... that is no consistency.
It's a hacker's paradise, not something a true engineer can or would be proud 
of.

> And lastly, to hopefully remove a little of that ignorance:  Python is 
> basically just a language specification.  The main development implementation 
> is called CPython
> because it is written in C and this is the Python most of us are familiar 
> with.  There are others, such as Jython (written in Java) and IronPython 
> (written in C#).
> There is even a PyPy which is a Python implementation written in
Python (which claims to be exceeding C in performance for some uses).
 For at least the C, Java, and 
> C# versions python will be able to use
libraries in their native languages (with some exceptions).

To me, it is unacceptable that for such a "cool", "hip" language, there is 
still no bundled compiler which compiles this wonderful code into a binary 
executable,
like a C compiler would.


In other words, I have seen Python. I even work with it every day. I looked at 
the code.

And I did not like what I saw, not one bit.
  
_
Keep your friends updated—even when you’re not signed in.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


> 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 Hotmail: Your friends can get your Facebook updates, right from 
Hotmail®.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-17 Thread Joerg Schilling

"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 board.  But
> they're a disaster in terms of marketing, installed base, and usability.
>
> But Sun has always been engineering rather than marketing driven, and
> frankly, that's why I like them. :-)

It seems that the type of engineer at Sun did change since the days of Bill Joy.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-17 Thread Joerg Schilling

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 of bummed my Operations folks out to 
> have to install Perl just for a few utilities that had previously been 
> written in C. (I ended up rewriting kstat for them in C, pretty easily).
>
> Now Python is needed for IPS, Xen, probably more. What other language 
> platforms are necessary?

+1 and BTW: I don't see that software written in scripting languages is easier 
to maintain than C programs.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-16 Thread Joseph Mocker

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 Operations folks out to
have to install Perl just for a few utilities that had previously been
written in C. (I ended up rewriting kstat for them in C, pretty easily).

Now Python is needed for IPS, Xen, probably more. What other language
platforms are necessary?

Although I realize that when you want to do something useful, like
install and run actual applications to solve business problems, you are
likely going to be installing one or both, or even something else, but
it would have been nice if Solaris engineering had decided on a small
set (read one) scripting language for anything in the base O/S. So the
O/S remains smaller, quicker to install, less language platforms to
support & maintain, etc.

Especially if you are getting performance by writing C modules for
critical functions, it kind of reduces the "we've got to use scripting
language X" argument.

Heck, last time I looked the O/S needs even a couple of different
versions of the Java JRE, even worse!

--joe

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 I've been writing about? Nice.

It is important to keep in mind that algorithms
generally matter more
than choice of programming language.

That is, in my experience only, quite a naive view of the industry and programming. By choosing
Python, you (plural) chose a programming language just because "Google does it", and
because it's "hip", not because it is the best tool for the job.

In fact, you pretty much chose a tool that most people are unfamiliar with, unless they too want to
be "hip" and "cool" at all costs. You've basically forced any would-be
contributor to go an learn Python, a language they might not need or want for anything else, if
they want to fix, revise or otherwise collaborate with you on the project.

I look at the choices that were made for IPS, and keep help but keep wondering,

WHY?

Who makes these decisions? What were they THINKING?

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-16 Thread Justin Fletcher

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 ZFS team to ditch C, and simply migrate it all to Python?
>

Are you dumb?  I mean..  really..   Are you generally considered to be a
little "slower" than others?   Knowing the answer to this question would
reduce a lot of effort in the replies.  It is a serious question.
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-16 Thread Justin Fletcher

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, short of writing
> IPS in assembler.
>
> The fact that some portions already had to be (re)written in C is proof
> enough that Python is not the best solution for the end product.
> --

You find optimizing Python with C as "Proof enough"?  An unfortunate
statement of ignorance (meant literally, not as an insult).

Optimizing Python (or better called CPython in this case, because that is
what it is) with C code is standard practice when performance of the running
application is significantly improved.  This is not a "proof" of anything
other than CPython being used as is common.

The time from development to deployment with Python is generally very low
and the code is also generally very easy to maintain.  This hopefully means
faster development with more stable, more maintainable, and less buggy
software and is the reason, I imagine, that it was chosen and accepted.
 Performance is a trade-off, but with C-optimizations (Pythonic C libraries)
the trade-off can be reduced significantly where needed.

As you mentioned, development in assembler would perform better, but it
would certainly be harder to maintain, improve, and port to other
architectures.  C is a maintainability and portability step up from
assembler, but with some performance loss.  Python is another step up from C
in maintainability (and possibly portability), but with some additional
performance loss.  Again, the C optimizations remove some of that loss, but
not all, and if there were assembler optimizations I doubt they would even
be considered regardless of performance improvements due to the
maintainability issue.  There are reasons higher level languages exist, and
they are good reasons.

To paraphrase someone else:  "Performance means a lot.  More than some
things, but not nearly as much as others."

And lastly, to hopefully remove a little of that ignorance:  Python is
basically just a language specification.  The main development
implementation is called CPython because it is written in C and this is the
Python most of us are familiar with.  There are others, such as Jython
(written in Java) and IronPython (written in C#).  There is even a PyPy
which is a Python implementation written in Python (which claims to be
exceeding C in performance for some uses).  For at least the C, Java, and C#
versions python will be able to use libraries in their native languages
(with some exceptions).
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-16 Thread Glynn Foster



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 decisions and your  
product will be.


And also, we will see what good is a product if it will be shunned  
and not accepted by the very people whose problems it was meant to  
solve.


Vote with your feet. Bye!


Glynn

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-16 Thread Glynn Foster

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 deliver my product for OpenSolaris.

So basically, here is the situation:

you have a progressive ISV, who WANTS to be ready and support your  
platform,
even though customers aren't paying him for it, but in order to do  
that, the ISV

basically has to invest double the effort to do so.

So even an enthusiastic ISV basically has to contend with  
unnecessary financial
burden, unnecessary because it was imposed by technical decisions  
which were
made with little or no input on what the customers really want or  
need, or how

they even use the existing product today.

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 currently support OpenSolaris? And when I write ISVs,  
I mean

companies like: CheckPoint, Oracle, Adobe, Veritas, ...

Most ISVs won't support short term releases of OpenSolaris, and that  
really isn't on our radar. They don't support other Linux  
distributions that are fast moving such as Fedora, Ubuntu, openSUSE  
either. However, ISV support for Solaris Next is obviously desired and  
expected.

Glynn
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-16 Thread a b


> 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 people
who actually be paying the bills.

> Its obvious you too care about the product, as you spend a great deal of 
> time talking about it :)

I absolutely care about the product. I care great deal about it; Solaris is
near and dear to my heart.

I've used Solaris ever since I was a kid, I grew up with it. I spent all of
my professional career in study and mastery of Solaris, and I love every
microsecond of it, and don't regret it one bit.

In fact, I feel extremely lucky that I did what I did.

But I disagree, from the very core of my being, and from my experience,
with the architectural, technical, and political decisions which were made
FOR ME as far as the OpenSolaris distribution, and IPS in particular is
concerned.

  
_
Windows Live Hotmail: Your friends can get your Facebook updates, right from 
Hotmail®.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


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 currently support OpenSolaris? And when I write ISVs, I mean
companies like: CheckPoint, Oracle, Adobe, Veritas, ...


If you're going to play a numbers game, then everyone should just use 
Windows, right?  Windows has the largest ISV support of any platform :)


--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-16 Thread a b

> 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 basically, here is the situation:

you have a progressive ISV, who WANTS to be ready and support your platform,
even though customers aren't paying him for it, but in order to do that, the ISV
basically has to invest double the effort to do so.

So even an enthusiastic ISV basically has to contend with unnecessary financial
burden, unnecessary because it was imposed by technical decisions which were
made with little or no input on what the customers really want or need, or how
they even use the existing product today.

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 currently support OpenSolaris? And when I write ISVs, I mean
companies like: CheckPoint, Oracle, Adobe, Veritas, ...

_
Windows Live: Friends get your Flickr, Yelp, and Digg updates when they e-mail
you.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_3:092010___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


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.

And also, we will see what good is a product if it will be shunned and not 
accepted by the very people whose problems it was meant to solve.


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.


Its obvious you too care about the product, as you spend a great deal of 
time talking about it :)


--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


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 well 
supported it is, where it is in use, and whether it is suitable for the 
problem you wish to apply it to.


If you profile the pkg(5) clients and tools as a whole, you'll find that 
a significant majority of the execution time is spent waiting on disk or 
network operations.  In short, performance generally doesn't matter for 
most of the operations performed by the client since it will spend most 
of its time waiting on things it has no control over.


As many recent studies have shown, interpreted languages can bring 
identical or acceptable performance levels for many operations when 
suitable algorithms are employed.  The significant advantages in ease of 
development, time required for development, and the long-term 
maintenance and support of a project make it clear that it is beneficial 
to employ a high-level language where appropriate.


--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

> 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 see what good is a product if it will be shunned and not 
accepted by the very people whose problems it was meant to solve.
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

> 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@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

> 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 Google is doing it, THEN IT'S THE WAY TO GO! No ifs, buts, or maybes.

I personally would pay for the plane ticket, lodging, and any other expenses 
just so I can be there to see Jeff Bonwick's face when that suggestion is made.
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


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 I've been writing about? Nice.


No, I just mentioned it as a point that an organisation that cares about 
performance and reliability found it a suitable choice.  The viability 
and growth of a tool's community is important when considering choice of 
development tools and language.



It is important to keep in mind that algorithms
generally matter more 
than choice of programming language.


That is, in my experience only, quite a naive view of the industry and programming. By choosing 
Python, you (plural) chose a programming language just because "Google does it", and 
because it's "hip", not because it is the best tool for the job.


That isn't the reason it was chosen, you're reading between the lines 
where there is nothing to be read.



WHY?

Who makes these decisions? What were they THINKING?


Welcome to a meritocracy.  Those that do the work get to make the 
decisions as they've earned the right to do so.


Cheers,
--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

> 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 about? Nice.

> It is important to keep in mind that algorithms
> generally matter more 
> than choice of programming language.

That is, in my experience only, quite a naive view of the industry and 
programming. By choosing Python, you (plural) chose a programming language just 
because "Google does it", and because it's "hip", not because it is the best 
tool for the job.

In fact, you pretty much chose a tool that most people are unfamiliar with, 
unless they too want to be "hip" and "cool" at all costs. You've basically 
forced any would-be contributor to go an learn Python, a language they might 
not need or want for anything else, if they want to fix, revise or otherwise 
collaborate with you on the project.

I look at the choices that were made for IPS, and keep help but keep wondering,

WHY?

Who makes these decisions? What were they THINKING?
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


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 that some portions already had to be (re)written in C is proof enough 
that Python is not the best solution for the end product.


It is only proof that *some* portions are better written in C, it is not 
proof that the product as a whole would be better written in C.


We welcome contributions of course if you're willing to work on 
performance-sensitive areas.


Otherwise, our development team is better spent on other issues.

--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

> 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 already had to be (re)written in C is proof enough 
that Python is not the best solution for the end product.
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-16 Thread 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
worthwhile, and only likely to delay adding actually needed features.

-- 
-Alan Coopersmith-   alan.coopersm...@sun.com
 Sun Microsystems, Inc. - X Window System Engineering

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-16 Thread Alan Coopersmith

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-   alan.coopersm...@sun.com
 Sun Microsystems, Inc. - X Window System Engineering

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-16 Thread Joseph Mocker


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 
or postremove?
  
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.


 --joe
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

> 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 is infamous for having notoriously 
bad marketing which does not understand the product they are trying to market, 
nor do they understand the target audience they are marketing to, at all.

This is not something that has happened over night, it has been this way for 
the past twenty years or so in the history of SUNW.

> In the end, we need to move on in a constructive way.
>  They're not
> oing to axe IPS and replace it with SysV packages or
> anything else.
> It's here to stay.  Same goes for AI and OpenSolaris
> as a whole.

OK, let's do something constructive: how about adding postinstall, postremove, 
preinstall and preremove "actions" to IPS?

How about implementing Flash(TM) or the equivalent of compressed flash archives?

How about migrating the Python code to C?

How's that for constructive suggestions?
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


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 
or postremove?


How can the script ensure that the sysadmin didn't change something on 
the system that wouldn't have rendered preinstall, postinstall, or 
preremove from working?


That's the problem with scripts like these; you can't guarantee the 
environment will be as the script expects.



 See this
blog entry for more 
information:


http://blogs.sun.com/sch/entry/pkg_1_a_no_scripting


This must be the Nth time you have pointed me to that blog, so let me in turn 
point certain things out:

...

And let me simply say that dozens of OpenSolaris builds have been 
delivered successfully without scripting within packaging execution 
context, so things cannot possibly be as dire as you propose them to be.



All the fancy musings, and all the fancy blog entries can not hide the fact 
that IPS is an artificial solution which has not been thouroughly thought 
through.


No, it has been thoroughly thought through, you just don't agree with 
the conclusions :)


--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

> 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?

> That's fine, we'll just have to disagree.

No we won't, because this is costing money.  Where can I send the bill, please?

>  See this
> blog entry for more 
> information:
> 
> http://blogs.sun.com/sch/entry/pkg_1_a_no_scripting

This must be the Nth time you have pointed me to that blog, so let me in turn 
point certain things out:

a) you seem to only echo what others have mused on the subject, and seem to 
explicitly hold that which they have mused about as absolute right and correct 
way to do and even think about things

b) I have read that blog about five minutes after it was posted, and it was 
posted on September 7, 2007

And I knew, right there and then, that we're going to be in heaps of trouble, 
if that "vision" was allowed to continue.

Engineers aren't infallible. We make mistakes too, and are subject to the NIH 
syndrome, and oft times subject to living in our own little perfect worlds.

The key to success is listening to our customers, study how they use the 
product, ask them what their needs are, spend the time with them in the 
trenches, instead of isolating oneself, and trying to solve non-existent 
problems by making them even worse.

And your customers, paying customers, in this day and age, are mostly 
experienced system administrators or even better, system engineers, who know 
exactly what the issues are and what they want and need.

They don't need someone else to tell them what they want, nor do they need 
someone else to decide what's good for them.

> You view usage of SMF as an abuse, but I view it as a
> change of 
> execution context.  pkg(5) doesn't say that you can't
> have scripting, it 
> just says that you can't have scripting as part of
> the package execution 
> context.

Perhaps you can come up with a solution for my first question above, on how to 
stop a sysadmin from inadvertently running an SMF method which must not execute 
until the package is removed?

And what about these SMF methods lingering around for the life of the package?

All the fancy musings, and all the fancy blog entries can not hide the fact 
that IPS is an artificial solution which has not been thouroughly thought 
through.
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-16 Thread Joerg Schilling

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
> manager sent trying to propose a way forward.

Well, there was no such mail. There is of course interest.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-16 Thread Alan Coopersmith

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
 Sun Microsystems, Inc. - X Window System Engineering

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-16 Thread Joerg Schilling

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 discouraged by the current situation.
>
> The necessary frameworks are in place for those that are committed to 
> contributing.  The contribution process may not be easy as it should be, 
> but it is possible to do so.

This is theory If contributions are prevented this will not result in 
contributions.

BTW: RFE 5007466 was closed, does this mean that star is now included in 
Solaris?

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-14 Thread Dave Miner


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, not theoretical
discussions over Python ./. Perl ./. C.

Yes, it's on my ToDo list... it's not *that* hard.  The only problem
is that lacking a Sun-endorsed sample, people will reinvent hundreds
of differently-shaped wheels.



As we get closer towards Solaris Next, we recognize that samples, 
how-to's, and so on are requirements and fully expect to provide a lot 
of transition aids such as that.  Contributions from users such as 
yourself would be very helpful.


Dave
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-14 Thread Alan Coopersmith



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 that Perl would be markedly faster here.)
>> And there can be only one?   Doesn't that mean perl was also a mistake since
>> Sun had already committed to sh as a scripting language available on the
>> miniroot?   (Just taking your argument to its logical conclusion
> 
> Good point.  I actually would have preferred a C implementation for pkg(5).

%  find . -name '*.c'
./util/misc/extract_hostid.c
./util/distro-import/ksh-wrapper.c
./brand/support.c
./modules/actions/_actions.c
./modules/arch.c
./modules/pspawn.c
./modules/liblist.c
./modules/elf.c
./modules/elfextract.c
./modules/solver/py_solver.c
./modules/solver/solver.c

The parts that benefit from being in C are in C.

> What gets lost in this discussion is the need for a bridge over the
> gap between you Sun engineers in your ivory tower designing pure and
> well-defined systems and us consultants and software developers needing
> to implement automation during system installation in some reasonable
> reproducible way.

Isn't that why we have opensolaris and the community discussions?

-- 
-Alan Coopersmith-   alan.coopersm...@sun.com
 Sun Microsystems, Inc. - X Window System Engineering

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-14 Thread Uros Nedic


Hi Volker,

I really hope that I exaggerate but when I spoke with one ofSenior Engineers of 
"Sandy Bridge" architecture duringIDF this September I realized where we go. To 
be worse,he also agreed, too, even he is working for Intel. The bestin Intel is 
their "Physical Electronics Research Department",and moving to smaller 
electronic components each two years.
Architecture is almost broken - they become hostages oftheir own success - X86 
architecture.
Same is happening with Microsoft - they also become hostagesof their own 
success - Windows NT.
They are trying to deploy the latest innovations inside chip/kernel,to improve 
their products but not to change interface. Parts ofWindows 7 has been 
completely rewritten to be faster just notto be ABI compatible with older 
versions of Windows productsline.
At some point in future this has to be stopped. This is whatI'm talking about. 
Software engineers (including me, but tryingto improve) live on account of 
improvement of computer architecturewhich in turn live on account of 
innovations in physical electronics,which does its job the best of all three 
industries.
Now I'll go a little bit into economy. Why people by X86?Because they are 
cheap! Why people buy Windows Serverplatform? Because it was cheap! So this is 
one of examplesof inefficiency or deviation of market economy, of which I'mby 
the way supporter but not fundamentalist.
If anyone care about that I could give list of books of well-knownResearchers, 
Professors, etc., to read about that. It wasalready written and well studied 
but industry/economy usuallyhas to come unfortunately to the dead to see 
mistakes. Then,price for recovering is usually very high.
Hope I clarified my perspective, at least a little bit.
Regards - Nedic
---
"Every kind of peaceful cooperation among men
 is primarily based on mutual trust and only
 secondarily on institutions such as courts of
 justice and police."

 - Albert Einstein (1879 - 1955)



> From: v...@bb-c.de
> Date: Mon, 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 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 such importantpiece
> > of software.
> 
> I think you are exaggerating a little. :-)
> 
> > Also, I would like to say that I believe that SPARC will stay on its lineto
> > be almost the best microprocessor available on the market. If we alltransit
> > to X86 all our knowledge in computer science will worth nothing.
> 
> Now you are exaggerating more than a little. :-)))
> 
> Let's look forward and make OpenSolaris and IPS and SMF a nice system
> on all platforms.
> 
> 
> Regards -- Volker
> -- 
> 
> Volker A. Brandt  Consulting and Support for Sun Solaris
> Brandt & Brandt Computer GmbH   WWW: http://www.bb-c.de/
> Am Wiesenpfad 6, 53340 Meckenheim Email: v...@bb-c.de
> Handelsregister: Amtsgericht Bonn, HRB 10513  Schuhgröße: 45
> Geschäftsführer: Rainer J. H. Brandt und Volker A. Brandt
  
_
Windows Live Hotmail: Your friends can get your Facebook updates, right from 
Hotmail®.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

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 such importantpiece
> of software.

I think you are exaggerating a little. :-)

> Also, I would like to say that I believe that SPARC will stay on its lineto
> be almost the best microprocessor available on the market. If we alltransit
> to X86 all our knowledge in computer science will worth nothing.

Now you are exaggerating more than a little. :-)))

Let's look forward and make OpenSolaris and IPS and SMF a nice system
on all platforms.


Regards -- Volker
-- 

Volker A. Brandt  Consulting and Support for Sun Solaris
Brandt & Brandt Computer GmbH   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim Email: v...@bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513  Schuhgröße: 45
Geschäftsführer: Rainer J. H. Brandt und Volker A. Brandt
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

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 markedly faster here.)
>
> And there can be only one?   Doesn't that mean perl was also a mistake since
> Sun had already committed to sh as a scripting language available on the
> miniroot?   (Just taking your argument to its logical conclusion

Good point.  I actually would have preferred a C implementation for pkg(5).
Anyway, water under the bridge.

> - I'm a heavy
> perl user myself, so think both perl & python have their place in the core
> OS.)

I certainly wouldn't advocate kicking out Python. :-)

What gets lost in this discussion is the need for a bridge over the
gap between you Sun engineers in your ivory tower designing pure and
well-defined systems and us consultants and software developers needing
to implement automation during system installation in some reasonable
reproducible way.

Regards -- Volker
-- 

Volker A. Brandt  Consulting and Support for Sun Solaris
Brandt & Brandt Computer GmbH   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim Email: v...@bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513  Schuhgröße: 45
Geschäftsführer: Rainer J. H. Brandt und Volker A. Brandt
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-14 Thread Alan Coopersmith

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 Solaris 11 that
would make you have to choose between the least common denominator and
supporting all the new features.   This is the same dilemma every OS provides
with new releases - "Do I have one common binary for all versions, or
customized ones that take advantage of newer features in newer releases?"
- it could be Solaris 8 vs. 10 (see the blastwave dilemma on linking to open
source libraries in the OS there for instance) or Windows XP vs. 7.

> But that costs tremendous amounts of effort and money; it's very expensive.
> 
> pkgadd(1M) could have been incrementally improved with the backgraph 
> algorithm in AWK and "the C programming language" books which the make(1) 
> tool also uses, why wasn't this done instead?
> pkgadd(1M) could have been incrementally improved, based on pkgtrans(1), to 
> have knowledge of true package clusters instead of the loose package 
> metacluster (like "SUNWCall"), why wasn't this done?
> pkgadd(1M)'s capability to install packages via http:// protocol could have 
> been extended further, coupled with the dependency resolution algorithm, to 
> automatically install any and all needed packages over the network, like yum 
> install and pkg_get(1M) do; why wasn't this done?

"Why did Sun have to create ZFS instead of just extending UFS more?"
"Why did Sun have to create SMF instead of just extending init.d scripts more?"
"Why did Sun have to move to GNOME instead of just extending CDE more?"
"Why did Sun have to move to SVR4 instead of just extending SunOS 4 more?"
"Why did Sun have to create SPARC instead of just building more 680x0 machines?"

Change is inevitable in IT - sometimes the amount of change you need to make is
so great that replacement is the most viable option (allowing side-by-side
implementations during the transition and for customers to transition at their
own speed).Some of these have been more painful than others, but the end
result was better than hacking new features into an old design they didn't fit
into.

> I understand you might not have the answers to these questions; but surely 
> someone inside of Sun Microsystems knows!

Yes, and Stephen and Bart have explained it quite a bit - if everything they've
said and written about their investigations of the options and the requirements
they gathered from the various major enterprise customers they talked to hasn't
convinced you, my third-hand repeating of what they said isn't going to help.

-- 
-Alan Coopersmith-   alan.coopersm...@sun.com
 Sun Microsystems, Inc. - X Window System Engineering

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-14 Thread Uros Nedic

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 such importantpiece of 
software.
Also, I would like to say that I believe that SPARC will stay on its lineto be 
almost the best microprocessor available on the market. If we alltransit to X86 
all our knowledge in computer science will worth nothing.
Uros

---
"Every kind of peaceful cooperation among men
 is primarily based on mutual trust and only
 secondarily on institutions such as courts of
 justice and police."

 - Albert Einstein (1879 - 1955)

> Date: Mon, 14 Dec 2009 09:47:22 -0800
> From: alan.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 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.
> > 
> > Hmmm... I will readily admit that you're working on fixing the
> > performance issues, and improving overall efficiency, so the situation
> > is better now than it was when pkg(5) was first released into the wild.
> > 
> > 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 markedly faster here.)
> 
> And there can be only one?   Doesn't that mean perl was also a mistake since
> Sun had already committed to sh as a scripting language available on the
> miniroot?   (Just taking your argument to its logical conclusion - I'm a heavy
> perl user myself, so think both perl & python have their place in the core 
> OS.)
> 
> -- 
>   -Alan Coopersmith-   alan.coopersm...@sun.com
>Sun Microsystems, Inc. - X Window System Engineering
> 
> ___
> opensolaris-discuss mailing list
> opensolaris-discuss@opensolaris.org

_
Windows Live Hotmail: Your friends can get your Facebook updates, right from 
Hotmail®.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-14 Thread Alan Coopersmith

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 little justification for this claim.
> 
> Hmmm... I will readily admit that you're working on fixing the
> performance issues, and improving overall efficiency, so the situation
> is better now than it was when pkg(5) was first released into the wild.
> 
> 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 markedly faster here.)

And there can be only one?   Doesn't that mean perl was also a mistake since
Sun had already committed to sh as a scripting language available on the
miniroot?   (Just taking your argument to its logical conclusion - I'm a heavy
perl user myself, so think both perl & python have their place in the core OS.)

-- 
-Alan Coopersmith-   alan.coopersm...@sun.com
 Sun Microsystems, Inc. - X Window System Engineering

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

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 for this claim.

Hmmm... I will readily admit that you're working on fixing the
performance issues, and improving overall efficiency, so the situation
is better now than it was when pkg(5) was first released into the wild.

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 markedly faster here.)

> Significant portion of softwares in use at large software installations
> for high-traffic providers such as Google are written in Python.

True.  So?

Many big things are written in JavaScript, PHP, etc.  I for one certainly
wouldn't want to see pkg(5) in PHP. :-)

> It is important to keep in mind that algorithms generally matter more
> than choice of programming language.

Quite right.

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, not theoretical
discussions over Python ./. Perl ./. C.

Yes, it's on my ToDo list... it's not *that* hard.  The only problem
is that lacking a Sun-endorsed sample, people will reinvent hundreds
of differently-shaped wheels.

Regards -- Volker
-- 

Volker A. Brandt  Consulting and Support for Sun Solaris
Brandt & Brandt Computer GmbH   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim Email: v...@bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513  Schuhgröße: 45
Geschäftsführer: Rainer J. H. Brandt und Volker A. Brandt
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-14 Thread Shawn Walker


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.


Significant portion of softwares in use at large software installations 
for high-traffic providers such as Google are written in Python.


It is important to keep in mind that algorithms generally matter more 
than choice of programming language.


Cheers,
--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

> > 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, great even, no problem with that at all!
>
> What makes me personally extremely angry and frustrated is the level of
> *aggresive* marketing and promotion of OpenSolaris as the be-all, end-all,
> "the next big thing", "THE Solaris.Next" and "use it today!", and then when
> one does actually attempt to use it and finds all these deficiencies, only
> THEN do the excuses start:
[...]

Well, I've watched this thread go by... we've been through this, on
this list and others, a number of times.

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 board.  But
they're a disaster in terms of marketing, installed base, and usability.

But Sun has always been engineering rather than marketing driven, and
frankly, that's why I like them. :-)

In the end, we need to move on in a constructive way.  They're not
going to axe IPS and replace it with SysV packages or anything else.
It's here to stay.  Same goes for AI and OpenSolaris as a whole.

What we need now is best practices guides/cookbooks/howtos/whatever on
how to overcome these deficiencies:  How to design packages so that 
they don't hamper IPS performance, how to create SMF services that do 
the jobs previously done by preinstall/postinstall and CAS. I want
blueprints, white papers, code samples, etc. etc.  Look at the Apple
knowledgebase to see it done right.

While ranting and raving feels good immediately, working on a good
documentation base that includes real life working samples of
"well-defined" packages will be more worthwhile in the long run.

Because I do want that database that springs to life just out of a
pkgadd... errr... pkg install. :-)


Regards -- Volker
-- 

Volker A. Brandt  Consulting and Support for Sun Solaris
Brandt & Brandt Computer GmbH   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim Email: v...@bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513  Schuhgröße: 45
Geschäftsführer: Rainer J. H. Brandt und Volker A. Brandt
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-13 Thread Ignacio Marambio Catán

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 is taken? cant i
install a package that delivers an action and set a have a package
depend on that one?
is there any predefined order in whch those actions run?

nacho

On Sun, Dec 13, 2009 at 9:58 PM, Shawn Walker  wrote:
> 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.  The man page explains all of
>>> this.
>>
>> Yeah, so what happens if my SVR4 package doesn't deliver any files, but
>> does all the work in those scripts instead?
>
> Then you'll have to re-create your package.
>
>> I still disagree about two main things, and those are that
>>
>> 1. there should be no pre- and postinstall scripts, i.e. only files should
>> be delivered
>
> That's fine, we'll just have to disagree.  See this blog entry for more
> information:
>
> http://blogs.sun.com/sch/entry/pkg_1_a_no_scripting
>
> Except, it isn't quite correct say that pkg(5) only expects "files" to be
> delivered.  It also allows for groups, users, drivers, SMF related items,
> and legacy SVR4 information.
>
>> 2. that SMF should be *ABUSED* as a backdoor for executing those.
>
> You view usage of SMF as an abuse, but I view it as a change of execution
> context.  pkg(5) doesn't say that you can't have scripting, it just says
> that you can't have scripting as part of the package execution context.
>
>> The fundamental problem is that the IPS packaging team believes that the
>> definition of a PACKAGE is ONLY that of *FILES*, while customers
>> (aforementioned military, banks, insurance companies, and fortune 100
>> companies in general) believe that a *PACKAGE* is a UNIT OF CONSISTENTLY
>> REPEATABLE, ENCAPSULATED *WORK*.
>
> Every packaging system has a different definition of what a package
> can/should consist of.  pkg(5), like other systems, has chosen a different
> definition or view of things.  There is nothing stopping you from continuing
> to encapsulate the set of repeatable work you desire to, but you will have
> to do so in a different way than you used to.
>
>> If you must cause pain, how about developing some sort of method to
>> automatically migrate pre- and postinstall and pre- and postremove scripts
>> to one or more one-time SMF methods?
>
> There are no plans to do so at this time, although that might be possible in
> the future.  Given that most of those scripts didn't work reliably in the
> past in all execution contexts, I doubt the conversion would be as useful as
> you might imagine.
>
> With that said, there has been a discussion of how to simplify delivery of
> these scripts to ease transition.
>
> Cheers,
> --
> Shawn Walker
> ___
> opensolaris-discuss mailing list
> opensolaris-discuss@opensolaris.org
>
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-13 Thread Shawn Walker


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.  The man page explains all of

this.


Yeah, so what happens if my SVR4 package doesn't deliver any files, but does 
all the work in those scripts instead?


Then you'll have to re-create your package.


I still disagree about two main things, and those are that

1. there should be no pre- and postinstall scripts, i.e. only files should be 
delivered


That's fine, we'll just have to disagree.  See this blog entry for more 
information:


http://blogs.sun.com/sch/entry/pkg_1_a_no_scripting

Except, it isn't quite correct say that pkg(5) only expects "files" to 
be delivered.  It also allows for groups, users, drivers, SMF related 
items, and legacy SVR4 information.



2. that SMF should be *ABUSED* as a backdoor for executing those.


You view usage of SMF as an abuse, but I view it as a change of 
execution context.  pkg(5) doesn't say that you can't have scripting, it 
just says that you can't have scripting as part of the package execution 
context.



The fundamental problem is that the IPS packaging team believes that the 
definition of a PACKAGE is ONLY that of *FILES*, while customers 
(aforementioned military, banks, insurance companies, and fortune 100 companies 
in general) believe that a *PACKAGE* is a UNIT OF CONSISTENTLY REPEATABLE, 
ENCAPSULATED *WORK*.


Every packaging system has a different definition of what a package 
can/should consist of.  pkg(5), like other systems, has chosen a 
different definition or view of things.  There is nothing stopping you 
from continuing to encapsulate the set of repeatable work you desire to, 
but you will have to do so in a different way than you used to.



If you must cause pain, how about developing some sort of method to 
automatically migrate pre- and postinstall and pre- and postremove scripts to 
one or more one-time SMF methods?


There are no plans to do so at this time, although that might be 
possible in the future.  Given that most of those scripts didn't work 
reliably in the past in all execution contexts, I doubt the conversion 
would be as useful as you might imagine.


With that said, there has been a discussion of how to simplify delivery 
of these scripts to ease transition.


Cheers,
--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-13 Thread UNIX admin

> 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, great even, no problem with that at all!

What makes me personally extremely angry and frustrated is the level of 
*aggresive* marketing and promotion of OpenSolaris as the be-all, end-all, "the 
next big thing", "THE Solaris.Next" and "use it today!", and then when one does 
actually attempt to use it and finds all these deficiencies, only THEN do the 
excuses start:

"yeah there are problems, but hey, it's OpenSolaris, so we still love him, 
right?"

"yeah it's not perfect, but it's the way to go"

"yeah it doesn't do that, that, AND no, it doesn't do that either, but it's 
really GREAT!"

So in the end it turns out that the only thing OpenSolaris does do is be a 
"we're still working on that feature" DESKTOP OS.

So if it's not cooked, by the admission of the very people that work on it, why 
is it being PUSHED so AGGRESIVELY by the people at Sun?

I can't even begin to pour in words my frustration and how angry that makes me, 
but believe me, it makes me very, very angry and frustrated.
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-13 Thread UNIX admin

> 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.

> 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.  The man page explains all of
> this.

Yeah, so what happens if my SVR4 package doesn't deliver any files, but does 
all the work in those scripts instead?

I still disagree about two main things, and those are that

1. there should be no pre- and postinstall scripts, i.e. only files should be 
delivered

and

2. that SMF should be *ABUSED* as a backdoor for executing those.

The fundamental problem is that the IPS packaging team believes that the 
definition of a PACKAGE is ONLY that of *FILES*, while customers 
(aforementioned military, banks, insurance companies, and fortune 100 companies 
in general) believe that a *PACKAGE* is a UNIT OF CONSISTENTLY REPEATABLE, 
ENCAPSULATED *WORK*.

How do you plan to reconcile those two views? Or are you going to outright try 
and FORCE people who have developed these technologies and have had them 
working for the past decade or more?

You know, customers have one advantage over the IPS development team, they have 
existing technology and experience already in place and know from *EXPERIENCE* 
that the definition of the "package as a unit of consistently repeatable work" 
works, and works very well.

On the other hand, we have the IPS team which is constantly saying "IPS is the 
way to go", and "we're not done yet, and we don't know what the final product 
will look like, but we're confident that our way is *better*".

So, what of it?

Now, even the abuse of SMF wouldn't be so terribly bad, SMF supported one-time 
SMF manifests, which it currently does not do (although it was planned), and 
the fact that adding one's own instances of a known service ("smtp:abcd") is 
currently non-trivial and REQUIRES quite a but of svccfg(1M) scripting.

If you must cause pain, how about developing some sort of method to 
automatically migrate pre- and postinstall and pre- and postremove scripts to 
one or more one-time SMF methods?

And, one problem which I could not solve, if you think of packages as a unit of 
work, and we have one-time SMF methods emulating pre- and postinstall and pre- 
and postremove scripts, how does one ensure that a sysadmin doesn't 
accidentally enable an SMF method which is the equivalent of a pre- or 
postremove SVR4 package script?
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-13 Thread Shawn Walker


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 bits.

Class action and other scripts are completely ignored.

The purpose of the SVR4 import support is to import payload content and 
basic package information.


Cheers,
--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-13 Thread UNIX admin

> 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 exactly gets "imported" / "pulblished" if the SVR4 has 
no physical payload except to do all the work with the pre and post scripts?
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-12 Thread ken mays

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/12/09, UNIX admin  wrote:

> 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, a prototype(4)
> file declares what the package payload is.
> 
> I believe that in IPS, this is called a bundle file or a
> package manifest perhaps?
> 
> Which tool creates this declaration of package content?



  
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-12 Thread Shawn Walker


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(4). In other words, a prototype(4) 
file declares what the package payload is.


I thought you were talking about bundle packages, not prototypes, sorry 
about that.



I believe that in IPS, this is called a bundle file or a package manifest 
perhaps?


A package manifest.


Which tool creates this declaration of package content?


pkgsend(1)

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.


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.  The man page explains all of this.


Cheers,
--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-12 Thread UNIX admin

> 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, a prototype(4) 
file declares what the package payload is.

I believe that in IPS, this is called a bundle file or a package manifest 
perhaps?

Which tool creates this declaration of package content?
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-12 Thread Che Kristo

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 current OpenSolaris with Solaris 10 in that environment is
disingenuous to say the least. Compare OpenSolaris with SXDE/SXCE...now tell
me how many banks are running that in production.

On Fri, Dec 11, 2009 at 13:19, Steven Sim  wrote:

>  This thread is getting a little vitriolic but I agree with UNIX admin's
> argument.
>
> I am a very firm supporter of Solaris, even in situations which are
> strongly anti Solaris.
>
> I also find that although the Sun OS staff and Opensolaris contributors are
> absolutely brilliant technically, they are a little disconnected from the
> real world.
>
> Unix admin's statement about Banks and such hit right to the point.
>
> He's right. Period.
>
> I support bringing back SXCE if Sun ever wants Enterprise customers to take
> Solaris or Open Solaris seriously.
>
> Warmest Regards
> Steven Sim
>
>
> UNIX admin wrote:
>
>  How are they worthless?   They all install fine,
> since compatibility was kept
> with the System V packaging system.
>
>
>  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.
>
> Banks for instance will laugh you right out of the conference room - they 
> won't touch anything but Solaris 10. So if one wants to earn a living, 
> software MUST run on an enterprise OS - in this case, that enterprise OS is 
> Solaris 10.
>
> That's my dilemma. And I believe I'm not alone, I talk to other ISVs, and 
> they too are feeling the pain, only hiding it: when I ask them about 
> OpenSolaris, they just laugh it off. And in truth, I am compelled to agree 
> with them - the stuff is unstable, and as long as I get answer like "don't 
> use /opt, stuff should go into /usr" from people that don't understand the 
> issues yet make decisions in OpenSolaris, I know I'm in trouble.
>
>
>
>
> ___
> opensolaris-discuss mailing list
> opensolaris-discuss@opensolaris.org
>
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


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 served via 
pkg.depotd(1m) or (in the future) distributed as an on-disk package.


If you're speaking of patch bundles, no such concept exists.

Instead, if you want to update one or more packages, just publish a new 
version for each one.


Clients that already have the package installed will only retrieve the 
files that changed in the new version.


This greatly simplifies updates and ensures that systems that install 
the new version for the first time and those that are upgrading from an 
older one get the exact same experience in the most efficient manner 
reasonably possible.


Cheers,
--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

> 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 bundle(4) file? 

11 Dec 2009 21:57 UX: NOTICE: last message repeated 17 times
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


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.


Publication documentation is somewhat incomplete as the system is still 
under heavy design and development as has been repeatedly stated.



And no tools to build packages.


That isn't true.  There are many tools that are available with IPS to 
create and publish packages.


Cheers,
--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

> 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

Re: [osol-discuss] Some Why?-Questions

> 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 build herself (I produce my own Flash(TM) builds based on 
Solaris 10).

Once that build passes regression testing with the new patch, it is labeled as 
production release.  This usually takes place at six month release cycles, 
although I do have automation in place to make it happen earlier, if the fix is 
critical.

An upgrade, of possibly thousands of systems in parallel, if performed by a 
single click in the web browser of a custom software deployment server, and 
it'll bring the target nodes down, the network detects them and automatically 
reflashes them with the new OS build.

There are no service interruptions at any point in this process, because the 
targets are nodes in clusters.

I can't currently do these things with OpenSolaris; and it bothers me greatly.

> 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.

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.

And no tools to build packages.

Compounded, it just exacerbates the pain.
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-11 Thread Ignacio Marambio Catán

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 tries to please 
> everybody and fails to satisfy either side.
>
> The only people clapping at how great OpenSolaris is are end-users, which do 
> not have the capacity to comprehend the issues. And that's unfair to 
> everybody involved.
> --
> This message posted from opensolaris.org
> ___
> opensolaris-discuss mailing list
> opensolaris-discuss@opensolaris.org
>
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

> 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 to please 
everybody and fails to satisfy either side.

The only people clapping at how great OpenSolaris is are end-users, which do 
not have the capacity to comprehend the issues. And that's unfair to everybody 
involved.
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


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

Re: [osol-discuss] Some Why?-Questions

> 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 and doubled the cost.

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.

But that costs tremendous amounts of effort and money; it's very expensive.

pkgadd(1M) could have been incrementally improved with the backgraph algorithm 
in AWK and "the C programming language" books which the make(1) tool also uses, 
why wasn't this done instead?

pkgadd(1M) could have been incrementally improved, based on pkgtrans(1), to 
have knowledge of true package clusters instead of the loose package 
metacluster (like "SUNWCall"), why wasn't this done?

pkgadd(1M)'s capability to install packages via http:// protocol could have 
been extended further, coupled with the dependency resolution algorithm, to 
automatically install any and all needed packages over the network, like yum 
install and pkg_get(1M) do; why wasn't this done?

I understand you might not have the answers to these questions; but surely 
someone inside of Sun Microsystems knows!

WHY?

Of course, the answer could be "if you really need it, you could do it 
yourself", and indeed, I can do it myself.

But then, I also have to logically ask myself: if I have to do it myself, what 
exactly do I need Sun engineers for? For what?

They are not giving me what I want or need, and I know how to do it myself, 
what do I need them for then? Seriously?

> "Radically"?   It's a different packaging system and
> installer, and a few
> default preferences different - something like 99% of
> the binaries are
> bit-for-bit identical.

A packaging subsystem can make or break the OS choice in lights out management 
environments, where one has to manage tens of thousands of systems completely 
non-interactively and automatically.

No Flash(TM) capability (or 1:1 equivalent of it) is also a very grave and 
serious flaw in OpenSolaris. I don't believe I'm capable of stressing and 
putting in words just how critical the capability of having a compressed image 
of a system stripped of all system-specific information is. It's ultra critical 
for large environments.

> That's exactly what OpenSolaris gives you today - a
> chance to test your
> software and prepare for the future and be ready for
> Solaris 11.  It's
> closer to that future than SX:CE is, and ending SX:CE
> simply stops you
> from wasting your time on dealing with the things
> that are known not to
> be part of the next Solaris enterprise release.

At double the effort and the cost, because the packaging system is radically 
different.

And very, very poorly documented!

For instance, what is the equivalent of pkgmk(1) for IPS?
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


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 not the fact the someone wants to install a 
pre-configured database.


The issue is the context of the execution of the script required to 
pre-configure one.


pkg(5) simply says that packaging context is not the correct execution 
context for arbitrary scripts.


You're free to use any other system mechanism available to do so.

--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions


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 frameworks are in place for those that are committed to 
contributing.  The contribution process may not be easy as it should be, 
but it is possible to do so.


--
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-11 Thread Joerg Schilling

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 like to change, it 
seems that the "indiana way" is not expected/wanted from either party.

Solaris people don't like to see GNU tools by default and Linux people would 
like to explore the Solaris extensions in the default set of tools.

Jörg

-- 
 EMail:jo...@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
   j...@cs.tu-berlin.de(uni)  
   joerg.schill...@fokus.fraunhofer.de (work) Blog: 
http://schily.blogspot.com/
 URL:  http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-11 Thread Alan Coopersmith

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. it has been stated on more than one occasion, that OpenSolaris the 
> distribution is the way forward.
> 
> But with OpenSolaris
> 
> a) being radically different

"Radically"?   It's a different packaging system and installer, and a few
default preferences different - something like 99% of the binaries are
bit-for-bit identical.   (Assuming you don't count the ones like Xsun & CDE
that aren't in both.)

> what do you believe, or what is your personal vision of what will replace 
> Solaris 10 in the enterprise space?

I believe the next version of Solaris will be based on the code you see today
in OpenSolaris, with a lot more work done to complete the new features that
are still in development.

> With SX:CE, the ISVs like myself have at least had a chance to test our 
> software and prepare for the future, and be ready for Solaris 11 (such as it 
> was until now); now, with the decision to kill SX:CE, the very ground we 
> stand on is being pulled from underneath us!

That's exactly what OpenSolaris gives you today - a chance to test your
software and prepare for the future and be ready for Solaris 11.  It's
closer to that future than SX:CE is, and ending SX:CE simply stops you
from wasting your time on dealing with the things that are known not to
be part of the next Solaris enterprise release.

-- 
-Alan Coopersmith-   alan.coopersm...@sun.com
 Sun Microsystems, Inc. - X Window System Engineering

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

> 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 ready for
> deployment to scenarios where you want to run the
> same OS for years without
> upgrading to new releases.   There's a reason it
> doesn't say "Solaris 11" on
> the CD labels yet.

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

2. it has been stated on more than one occasion, that OpenSolaris the 
distribution is the way forward.

But with OpenSolaris

a) being radically different

and b) not being in any shape or form ready for the enterprise, as stated here,

what do you believe, or what is your personal vision of what will replace 
Solaris 10 in the enterprise space?

With SX:CE, the ISVs like myself have at least had a chance to test our 
software and prepare for the future, and be ready for Solaris 11 (such as it 
was until now); now, with the decision to kill SX:CE, the very ground we stand 
on is being pulled from underneath us!

Sure OpenSolaris might have SVR4 packaging tools, but it is no secret that 
those are meant for backward compatibility only - which means that sooner or 
later someone intends for the ISVs to migrate fully to IPS, or be stuck with 
something that will become akin to /usr/ucb.

In my view, that is not a particularly warming or reassuring prospect, 
ultimately, all the units of work which we packaged up are obsolete, and the 
only way we can even begin to port to the new system is double effort and 
trying to execute the work using SMF as the back door.

Now THAT is broken by design, "works-as-designed". System engineers and 
developers shouldn't have to resort to using SMF as the back door to reach CMM 
level 2 and above.

> [BTW, like everything else you see on this mailing
> list, from everyone else
> involved, this is *me* speaking, one person, not the
>  voice of the company.
> If you want an official Sun statement, contact the
> press office for a finely
> tuned press release in which all the content is
>  scrutinized and sanitized.]

Understood. And thank you for your thoughts.
-- 
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-11 Thread ken mays

> 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, this is an apple to orange case. The OpenSolaris project 
is not directly comparable to an enterprise OS software release. The OSOL 
2009.06 Live CD is a "core" OS distro release which again is not directly 
comparable to any major enterprise software OS release. SXCE is not a 
considered as an enterprise OS production release so it would be unwise to 
label it as such to do its ALPHA/BETA origin. Any IT manager or system admin 
can install these snapshots releases in a data center and have a go at them - 
but must do so with extreme caution due to the ALPHA/BETA conditions of the 
releases.

There is no TRUE production release of an OpenSolaris distro today. Definitely 
not a 'enterprise-grade' OpenSolaris distribution. There was never an 
enterprise-grade release of the core "OSOL Live CD" concept. Someone at Sun 
marketing or elsewhere correct me on this. A third-party companies are making 
appliances and doing migration projects using an OpenSolaris release but these 
are special case projects. 

You cannot technically consider an OpenSolaris distro on the same level of a 
Debian-based distro. We'd just sit here and tell each other what does not work 
"yet" on the OpenSolaris distro versus what works or was developed/ported on a 
Debian-based distro. Kinda like comparing a Captain in the military to a First 
Lieutenant. Field experience counts for something - I hope.

> > 
> > Banks for instance will laugh you right out of the
> conference room - they won't touch anything but Solaris 10.
> So if one wants to earn a living, software MUST run on an
> enterprise OS - in this case, that enterprise OS is Solaris
> 10.

I agree with this statement. I'd laugh too since you'd hope system admins  will 
run enterprise-grade applications on an enterprise-grade OS. Not always the 
case in reality, but we can only dream - can't we?

> Alan CooperSmith wrote:
> 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 ready for  deployment to scenarios where you want to run the same OS
> for years without upgrading to new releases.   There's a  reason it doesn't 
> say "Solaris 11" on
> the CD labels yet.
> 
> 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.
> 

Yes, Since the inception of the OpenSolaris project many people understood that 
the 'biweekly' releases are "works in progress" as well as "ENGINEERING 
RELEASES" which consolidate to the BETA/RC/RTM releases around the near six 
month cycle (i.e. the 2008.11, 2009.06, 2010.03 releases). All the questions 
about SVR4 packaging and default bash shells are good points to bring up. Yet, 
we have SVR4 packaging support and options of various shells. People chose 
whether to use hammers versus nail guns - so you pick what suits you. 
Hopefully, these questions will only make the final product release much better 
due to user comments like the ones provided in this email thread.

Ken Mays
Atlanta, GA

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions

2009-12-11 Thread McDonald, Kyle

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?

  -Kyle

-Original Message-
From: opensolaris-discuss-boun...@opensolaris.org on behalf of Shawn Walker
Sent: Thu 12/10/2009 10:19 PM
To: 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 consistently and repeatably 
> create databases via packages.

But there is something broken about abusing the package installation 
process to setup something as complex as a database in my view.

-- 
Shawn Walker
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

Re: [osol-discuss] Some Why?-Questions