subject:"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

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


 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


 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

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


 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


 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

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


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

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 m...@sun.com wrote:


While I don't entirely agree with UNIX admin, I am sort of concerned
with the growing number of scripting environments that are now  
required

to make [Open]Solaris run.

First I realized that Perl was needed was when I discovered the kstat
was rewritten in Perl, which kind of bummed my Operations folks out  
to
have to install Perl just for a

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

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


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

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

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

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

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:

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

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:

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 Bart Smaalders


Shawn Walker wrote:

Craig S. Bell wrote:
Let me play devil's advocate: If people have the option to continue 
using the old package system (with it's action scripting 
capabilities), then could that slow adoption of the new pkg format?  
Or is that just the cost of providing compatibility?


I 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):
 


 long list elided

Not to mention:

* Automated install of transitive closure of dependency graph.

* Automated detection of package dependencies part of publication
  tool chain.

* Manifest signing support that allows cryptographic verification
  of all package contents, and supports addition of signatures
  to indicate approval for installation in various contexts.

* Faceted packages allow package publishers to provide various
  locales, documentation, developer support as part of single package.
  Also allows alternate platform support to be elided for
  minimization purposes; elided portions of packages are easily
  restored.

* Fast enough at generation of packages and update to allow developers
  to use native packaging rather than workarounds (bfu  Install);
  this should significantly improve packaging quality and reduce
  errors.

* Elimination of alternative patching mechanism means no going back
  to repatch systems after installation of new packages; added packages
  are always correct for current revision level of system.

* Reduction of change stream development costs (no patch scripts to
  write!) offers easier opportunity to deliver tailored change streams
  to Sun customers.

- Bart

--
Bart Smaalders  Solaris Kernel Performance
ba...@cyber.eng.sun.com http://blogs.sun.com/barts
You will contribute more with mercurial than with thunderbird.
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org

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

2009-12-16 Thread Joerg Schilling

Shawn Walker swal...@opensolaris.org wrote:

 Joerg Schilling wrote:
  UNIX admin tripivc...@hotmail.com wrote:
  
  How many Juergen Keils and Masayuki Murayamas are out there in the 
  community?
  
  There are more but Sun does not yet have the collaboration infrastructure 
  to 
  get them 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-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

Alan Coopersmith alan.coopersm...@sun.com wrote:

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

 No, according to the bug database, it was closed due to lack of interest,
 since no one from the community responded to the mail the 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

 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


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

 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

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

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

 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


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

 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:

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.

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

 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

 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


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


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

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


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


 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

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 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 Justin Fletcher

On Wed, Dec 16, 2009 at 11:09 PM, UNIX admin tripivc...@hotmail.com wrote:

  What would the benefit of that be?

 The target audience, which is sysadmins and system engineers, is familiar
 with C, and the project stands to benefit from that expertise.

 Not to mention that C will give you maximum 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 Justin Fletcher

On Wed, Dec 16, 2009 at 11:24 PM, UNIX admin tripivc...@hotmail.com wrote:

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

 Something else just occurred to me: since Google does it, why don't we go
 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 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

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

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

2009-12-14 Thread Uros Nedic

I really do not see need for Python, Perl and other scripting languagesto be
placed in SunOS. I believe that SUN has to buy Design Patternsand
Refactoring to patterns books along with The art of computer scienceand
share to their developers to continue developing perfect such 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

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

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

Hi Uros!


 I really do not see need for Python, Perl and other scripting languagesto
 be placed in SunOS. I believe that SUN has to buy Design Patternsand
 Refactoring to patterns books along with The art of computer scienceand
 share to their developers to continue developing perfect such 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

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

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

 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 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 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 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 swal...@opensolaris.org 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-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 unixan...@gmail.com 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

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 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 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 tripivc...@hotmail.com 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-11 Thread Joerg Schilling

UNIX admin tripivc...@hotmail.com wrote:

 How many Juergen Keils and Masayuki Murayamas are out there in the community?

There are more but Sun does not yet have the collaboration infrastructure to 
get them involved, people are even discouraged by the current situation.

Jörg

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

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

You go ahead and tell that to all those banks which run world's trading  
exchange systems, and all those insurance companies, and the military. Tell 
them their super-stable, highly available systems with thousands of such 
packages are broken.

I actually witnessed Sun coming in one such time and telling the customer all 
about how super-duper OpenSolaris is, and how IPS is the future, and a no 
scripting zone, until people in the room said wait, we have thousands of 
configuration packages, and have had them for the last 10 years! This IPS stuff 
will break all of that! And the Sun guy's jaw dropping on the floor... that 
OpenSolaris pitch did not go down well.

What is the difference between delivering a binary executable, and a 
preconfigured /etc/inet/ntp.conf? There isn't any. A package is supposed to 
deliver encapsulated unit of work, not simply binary executables. If we were to 
follow your logic, delivering any configuration files, or adapting them to the 
system on-the-fly is broken, and that's absurd.

Just because you can't imagine it, that doesn't mean it's broken, or that it 
doesn't exist.
-- 
This message posted from opensolaris.org
___
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

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

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

2009-12-11 Thread Joerg Schilling

UNIX admin tripivc...@hotmail.com wrote:

 Agreed, and you're right. Perhaps you might answer me this:

 1. SX:CE, the closest one has ever come to Solaris 11, is being killed

The problem is that there was no discussion on how Solaris should be extended.
From talking to both Solaris sysadmins and 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 Shawn Walker


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

 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

2009-12-11 Thread Shawn Walker


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

 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

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 tripivc...@hotmail.com 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

 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

 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

2009-12-11 Thread Shawn Walker


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