On 9/10/12 11:36 AM, Shawn Walker wrote:
On 09/10/12 11:26, Philip Brown wrote:
...
This is backwards. Priority should be on speed of normal operation, not
on esoteric searches.
Again, pkg(5) is not a tarball extractor, and never will be.
The design of pkg(5) has often chosen correctness and user experience
over performance where it matters.
Flawed comparisons with systems that do not have equivalent
functionality or correctness guarantees can only lead to tears.
Speed of execution IS "user experience", and a primary part of it.
It's disappointing to see, yet again, a whole bunch of excuses of,
"everything is fine we know what we're doing", rather than a simple
admission of,
"Hey, you're right, that's really bad performance. We'll work on it"
You're solving problems that almost no one cares about, and you ARENT
solving the problems that people DO care about.
For a comparison: ZFS was accepted as the new way of handling
filesystems, not just because it added a whole bunch of cool features,
but because it did so *while not adding noticable performance penalties*.
If "cool features" get in the way of user acceptable performance, it's
time to either ditch the features, or rewrite the implementation.
As I mentioned in my prior email, yum does pretty much all the stuff you
were touting, but does it in 1/4 the time that 'pkg' currently does.
Therefore, pkg does not have acceptable performance at present.
The other features like "variants", and "boot environments" should not
be a delaying factor, if they are not used by the package being deployed.
(If they are a delaying factor, then it's a BUG in the implementation!)
It will be interesting to see what Oracle corp will do, when people
outside the organization eventually come up with a more user desirable
replacement for a software system that they are paying people to write.
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
