On Thu, Aug 27, 2009 at 04:32:28PM -0500, Shawn Walker wrote:
> Jyri Virkki wrote:
> >My bet is that once IPS leaves the lab playground and into the
> >production floor features such as this one (or equivalent
> >functionality) which are ugly but necessary in real production use
> >will soon be escalated into existence.
>
> There's an implicit assumption here that is wrong. That is, that the
> developers of pkg(5) have never been system administrators or been 'part
> of the real world' and therefore are designing a packaging system in
> some far-off ivory tower where form over function is king.
...
IPS is here, IPS is not going away (unless... see below). IPS needs
performance improvements. IPS needs additional features, such as
manifest signing and what not.
To continue this acrimonious discussion at this point, so long after the
project's inception, and after so many similar threads in the past, is
just a waste of time.
Features can clearly be added (except where they are antithetical to
IPS, such as pkg install/uninstall context scripting).
What we need to know is:
Q: Are the performance problems the result of a fatal flaw in IPS that
would be too difficult to fix?
That's the only really important question. Because if the answer is
"yes", then every minute we don't spend scrapping IPS is a minute lost.
I suspect that the answer is "no". My bet is that Python suffers from
the LISP aphorism that programmers know the value of every expression
and the cost of none. IPS is written in Python.
For example: imagine an IPS action generator at the core of pkg install,
then imagine that some developer ran into some problem such that a
simple solution was to gather all actions, inspect them, then evaluate
them. That's easy to do! -- just a few insignificant characters. But
suddenly you need enough memory to hold the Python program's
representation of each and every action in memory at once. IIUC this
did happen at one point, and was the reason that the initial pkg install
required something like 600MB of RAM.
Now, some kinds of programming mistakes can be really hard to correct
down the road, by which I mean that lots of code may need to get
re-factored or re-written. I hope that's not the case here. Has
someone profiled the unduly slow IPS operations to find out what makes
them slow? Has DTrace been brought to bear on the problem? Is it
inefficient algorithms? Python? What? To answer the crucial question
asked above someone must start by profiling IPS.
Nico
--
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
