Mailinglist Archive: opensuse-factory (392 mails)
| < Previous | Next > |
Re: [opensuse-factory] Announcement: Software management for openSUSE
- From: Eberhard Moenkeberg <emoenke@xxxxxxx>
- Date: Thu, 19 Apr 2007 00:45:48 +0200 (CEST)
- Message-id: <Pine.LNX.4.64.0704190023050.14632@xxxxxxxxxxxxxx>
Hi,
On Wed, 18 Apr 2007, Cristian Rodriguez R. wrote:
> Eberhard Moenkeberg escribió:
> > But unfortunately not for SLES - there the hassle has to go on (by order),
> > and that may affect the business part of SUSE/Novell.
>
> well.. you probably know what happends to a part of a commercial product
> if cause to loose money..it becomes either an documented bug or
> disappears..that pressure is higher than comunnity pressure I guess ;-P
Surely, they have to turn "bad" management decision into "good" result,
but without help of the community now.
> > Let's hope this shit will turn into gold without help from the community.
> > Not the best chance...
>
> It probably has a chance to improve if
>
> 1. is not marketed as be integrated with yast ( integration will never
> work, it hurts so much...)
>
> 2. if rug is separated from the zmd daemon (yes,rug is fine IMHO) and
> ZMD dissapears from the scene.
>
> 3. it is fixed to achieve better performance (I guess that requires
> fixing not only Zenworks but mono and other components)
Surely, almost everytime high-level is low-performance. But this is not
known to managers: they have to deserve it in practice before they
"believe" it (almost never "understand"). This result usually is coming
too late for the business.
> Finally, Im pleased with this announce and invite the rest of the
> contributors to test zypper and related stuff **madly**. I can now stop
> bugging people about Zenworks problems and use my time in a more
> productive and less annoying task.
Yes. But I fear about SLES usage quality - we have more than 1000 licenses
here - already lowered by number against the past years due to changed
pricing models (more money for the same number of servers - obviously
Novell does not reflect RedHat's "educational" prices); our new license
contract may be the last by two reasons now...
Viele Grüße
Eberhard Mönkeberg (emoenke@xxxxxxx, em@xxxxxxx)
On Wed, 18 Apr 2007, Cristian Rodriguez R. wrote:
> Eberhard Moenkeberg escribió:
> > But unfortunately not for SLES - there the hassle has to go on (by order),
> > and that may affect the business part of SUSE/Novell.
>
> well.. you probably know what happends to a part of a commercial product
> if cause to loose money..it becomes either an documented bug or
> disappears..that pressure is higher than comunnity pressure I guess ;-P
Surely, they have to turn "bad" management decision into "good" result,
but without help of the community now.
> > Let's hope this shit will turn into gold without help from the community.
> > Not the best chance...
>
> It probably has a chance to improve if
>
> 1. is not marketed as be integrated with yast ( integration will never
> work, it hurts so much...)
>
> 2. if rug is separated from the zmd daemon (yes,rug is fine IMHO) and
> ZMD dissapears from the scene.
>
> 3. it is fixed to achieve better performance (I guess that requires
> fixing not only Zenworks but mono and other components)
Surely, almost everytime high-level is low-performance. But this is not
known to managers: they have to deserve it in practice before they
"believe" it (almost never "understand"). This result usually is coming
too late for the business.
> Finally, Im pleased with this announce and invite the rest of the
> contributors to test zypper and related stuff **madly**. I can now stop
> bugging people about Zenworks problems and use my time in a more
> productive and less annoying task.
Yes. But I fear about SLES usage quality - we have more than 1000 licenses
here - already lowered by number against the past years due to changed
pricing models (more money for the same number of servers - obviously
Novell does not reflect RedHat's "educational" prices); our new license
contract may be the last by two reasons now...
Viele Grüße
Eberhard Mönkeberg (emoenke@xxxxxxx, em@xxxxxxx)
| < Previous | Next > |