On Tue, May 23, 2006 at 08:24:50AM +0200, Frank-Michael Fischer wrote:

Mr Ubuntu and Mrs Fedora will like it too. Actually I am not using SUSE on my own desktop anymore, waiting for some statement like "we drop Zen" or "we are going to use something very different and will just call it Zen". Zen is like Lotus 1-2-3: a real killer application ;-)

I use SUSE on my machine. 10.0 works great. -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

Heiko Helmle wrote:

Frank-Michael Fischer wrote:

...

Might sound a bit emotional, but the "parse-metadata" problem turns 10.1 into a virtually unusable desktop for my customers (and me) really. In certain server setups it might be acceptable that the system needs up to 30 minutes after reboot before giving full power to the users. But on a desktop?

As a workaround i'd suggest to disable zmd and configure smart. It's quite fast and doesn't take 5 minutes to wake up some background daemon just to search for a package. (Packages smart and smart-gui are on the OpenSUSE CDs).

You'll lose that little update icon on your desktop - which means you should do 'smart update' occasionally.

Together with a little restriction on beagle (as suggested by others on this list) you should get a pretty speedy SUSE Experience.

Regards Heiko

Great, thanks. Just one suggestion: I wouldn't call disabling zen a "workaround"; it's THE solution. FMF

Hello, Marcus Meissner wrote:

On Tue, May 23, 2006 at 08:08:02AM +0200, Frank-Michael Fischer wrote:

...

Might sound a bit emotional, but the "parse-metadata" problem turns 10.1 into a virtually unusable desktop for my customers (and me) really. In certain server setups it might be acceptable that the system needs up to 30 minutes after reboot before giving full power to the users. But on a desktop?

We cannot confirm this behaviour.

parse-metadata occassionaly leads to a slow down, but only a minute at most and not on bootup.

It's an often reported bug on the Hungarian SUSE mailing list, so I can confirm this behavior. AFAIK it's a problem on slower machines, and comes combined with beagle. But 'parse-metadata' is the most often reported resource hog.

You are overblowing the issue.

I think, he is right for slower machines, but it's a non issue on recent machines (max 2 years old).

/etc/init.d/novell-zmd stop rpm -e zmd rug zen-updater

Is there any functionality lost this way? I know, that the update icon from the tray will be gone, which is a positive change for me :-) Anything else? Bye, CzP -- CzP http://peter.czanik.hu/

...

You are overblowing the issue.

I think, he is right for slower machines, but it's a non issue on recent machines (max 2 years old).

...

/etc/init.d/novell-zmd stop rpm -e zmd rug zen-updater

Is there any functionality lost this way? I know, that the update icon from the tray will be gone, which is a positive change for me :-) Anything else? Bye,

No. YaST2 online_update will work fine. However, there is unfortunately no commandlinetool to install updates then. Ciao, Marcus

On Tue, May 23, 2006 at 10:00:18AM +0200, Kevin Ivory wrote:

On 2006-05-23 09:46 (and 09:05), Marcus Meissner wrote:

...

...

...

/etc/init.d/novell-zmd stop rpm -e zmd rug zen-updater [Peter Czanik ] Is there any functionality lost this way? I know, that the update icon from the tray will be gone, which is a positive change for me :-) Anything else? Bye,

No. YaST2 online_update will work fine.

However, there is unfortunately no commandlinetool to install updates then.

fou4s might work: http://fou4s.gaugusch.at/ has been a "fast online update 4 suse" command line tool for many SUSE versions now. Haven't tested it on SUSE 10.1 yet, though.

I guess you could just use "yum" natively too. Ciao, Marcus

Peter Czanik wrote:

Hello,

Marcus Meissner wrote:

...

On Tue, May 23, 2006 at 08:08:02AM +0200, Frank-Michael Fischer wrote:

...

Might sound a bit emotional, but the "parse-metadata" problem turns 10.1 into a virtually unusable desktop for my customers (and me) really. In certain server setups it might be acceptable that the system needs up to 30 minutes after reboot before giving full power to the users. But on a desktop?

We cannot confirm this behaviour.

parse-metadata occassionaly leads to a slow down, but only a minute at most and not on bootup.

It's an often reported bug on the Hungarian SUSE mailing list, so I can confirm this behavior. AFAIK it's a problem on slower machines, and comes combined with beagle. But 'parse-metadata' is the most often reported resource hog.

...

You are overblowing the issue.

I think, he is right for slower machines, but it's a non issue on recent machines (max 2 years old).

...

/etc/init.d/novell-zmd stop rpm -e zmd rug zen-updater

Is there any functionality lost this way? I know, that the update icon

...

from the tray will be gone, which is a positive change for me :-) Anything else? Bye, CzP

These are three machines showing this bug: 2GHz/512MB, 2.2GHz/512MB and 2.8GHz/1GB. Older, slow machines? FMF

Andreas Jaeger wrote:

Frank-Michael,

have you done an update from a previous beta/RC on these machines?

What's the output of: * rug sl * rug ca

Andreas

No updates, just installations from scratch. There is no rug anymore on my machines so I couldn't tell you the output of these commands. FMF

Frank-Michael,

have you done an update from a previous beta/RC on these machines?

What's the output of: * rug sl * rug ca

Andreas

Andreas Jaeger wrote: linux:~ # rug sl # | Status | Type | Name | URI --+--------+------+--------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------- 1 | Active | ZYPP | SUSE-Linux-10.1-FTP-EXTRA-10.1-0-20060512-060816 | ftp://ftp4.gwdg.de/pub/opensuse/distribution/SL-10.1/non-oss-inst-source?alias=SUSE-Linux-10.1-FTP-EXTRA-10.1-0-20060512-060816 2 | Active | ZYPP | SUSE-Linux-10.1-FTP-10.1-0-20060512-060713 | ftp://ftp4.gwdg.de/pub/opensuse/distribution/SL-10.1/inst-source?alias=SUSE-Linux-10.1-FTP-10.1-0-20060512-060713 3 | Active | ZYPP | SUSE-Linux-10.1-Add-on-10.1-0-20060512-071716 | nfs://little.cp//CDNONOSS?alias=SUSE-Linux-10.1-Add-on-10.1-0-20060512-071716 4 | Active | ZYPP | SUSE-Linux-10.1-CD-download-x86-10.1-0-20060512-071731 | nfs://little.cp/CD1?alias=SUSE-Linux-10.1-CD-download-x86-10.1-0-20060512-071731 5 | Active | ZYPP | SUSE-Linux-10.1-Updates | http://ftp.tu-chemnitz.de/pub/linux/suse/ftp.suse.com/suse/update/10.1/ 6 | Active | ZYPP | 20060512-104623 | http://packman.mirrors.skynet.be/pub/packman/suse/10.1 linux:~ # rug ca Sub'd? | Name | Service -------+--------------------------------------------------------+------------------------------------------------------- Yes | SUSE-Linux-10.1-FTP-10.1-0-20060512-060713 | SUSE-Linux-10.1-FTP-10.1-0-20060512-060713 Yes | SUSE-Linux-10.1-FTP-EXTRA-10.1-0-20060512-060816 | SUSE-Linux-10.1-FTP-EXTRA-10.1-0-20060512-060816 Yes | SUSE-Linux-10.1-Add-on-10.1-0-20060512-071716 | SUSE-Linux-10.1-Add-on-10.1-0-20060512-071716 Yes | SUSE-Linux-10.1-Updates | SUSE-Linux-10.1-Updates Yes | 20060512-104623 | 20060512-104623 Yes | SUSE-Linux-10.1-CD-download-x86-10.1-0-20060512-071731 | SUSE-Linux-10.1-CD-download-x86-10.1-0-20060512-071731 Strange thing: rug says "active" for some services but yast: Status│Refresh│Name │URL Off │Off │SUSE Linux Add-on 10.1│nfs://little.cp//CDNONOSS Off │Off │SUSE Linux 10.1 │nfs://little.cp/CD1 FMF

On Tue, 23 May 2006, Andreas Jaeger wrote:

...

linux:~ # rug sl

# | Status | Type | Name | URI --+--------+------+--------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------- 1 | Active | ZYPP | SUSE-Linux-10.1-FTP-EXTRA-10.1-0-20060512-060816 | ftp://ftp4.gwdg.de/pub/opensuse/distribution/SL-10.1/non-oss-inst-source?alias=SUSE-Linux-10.1-FTP-EXTRA-10.1-0-20060512-060816

...

2 | Active | ZYPP | SUSE-Linux-10.1-FTP-10.1-0-20060512-060713 | ftp://ftp4.gwdg.de/pub/opensuse/distribution/SL-10.1/inst-source?alias=SUSE-Linux-10.1-FTP-10.1-0-20060512-060713

The ftp tree is rather large. If you remove it, your system is much faster. This tree has 20 MB of *compressed* xml metadata, downloading and parsing it takes time - too much right now.

My guess would be that most of the time is spent downloading the metadata. In any case, I'd suggest you try ftp-1.gwdg.de instead of ftp4.gwdg.de Regards Christoph

Anders Norrbring writes:

Andreas Jaeger skrev:

...

Frank-Michael, have you done an update from a previous beta/RC on these machines? What's the output of: * rug sl * rug ca

The first 'rug sl' command took 10 minutes to complete... This is on a dual Opteron 250 system with 8GB of RAM.

rug sl

# | Status | Type | Name | URI

--+---------+------+-----------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------- 1 | Pending | ZYPP | SUSE-Linux-10.1-FTP-10.1-0-20060513-122501 | ftp://ftp.sunet.se/pub/Linux/distributions/opensuse/distribution/SL-10.1/inst-source?alias=SUSE-Linux-10.1-FTP-10.1-0-20060513-122501 2 | Pending | ZYPP | SUSE-Linux-10.1-CD-download-x86_64-10.1-0-20060513-125447 | ftp://192.168.222.10/pub/10.1_x86_64/CD1?alias=SUSE-Linux-10.1-CD-download-x86_64-10.1-0-20060513-125447

3 | Pending | ZYPP | SUSE-Linux-10.1-Updates | http://ftp.gwdg.de/pub/suse/update/10.1/

4 | Pending | ZYPP | SuSE-Linux-FACTORY-10.1-factory-20060515-083354 | ftp://xxx.xxx.xxx/SL-OSS-factory/inst-source?alias=SuSE-Linux-FACTORY-10.1-factory-20060515-083354

5 | Pending | ZYPP | SUSE-Linux-10.1-FTP-EXTRA-10.1-0-20060516-214503 | ftp://xxx.xxx.xxx/SL-10.1/non-oss-inst-source?alias=SUSE-Linux-10.1-FTP-EXTRA-10.1-0-20060516-214503

6 | Pending | ZYPP | SUSE-Linux-10.1-FTP-10.1-0-20060516-220034 | ftp://xxx.xxx.xxx/SL-10.1/inst-source?alias=SUSE-Linux-10.1-FTP-10.1-0-20060516-220034

You have quite a lot sources and even duplicates. I suggest to remove those that you do not need. 1, 2, and 6 are all the same. I would remove either 1 or 6. No. 1,2,4 and 6 are quite large, the meta data for each are around 50 MB, so the download alone takes time - and then comes parsing... Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On Tue, May 23, 2006 at 11:24:17AM +0200, Anders Norrbring wrote:

Andreas Jaeger skrev:

...

Frank-Michael,

have you done an update from a previous beta/RC on these machines?

What's the output of: * rug sl * rug ca

Andreas

Apparently it's the wake-up of Zen that takes forever.. It loads both CPUs to 100% while coming to life. When alive sommands go instantly, no more than 0.3 seconds to execute just about anything that doesn't involve checking sources online, while doing the same things with zmd.exe in sleep state takes between 1.5 and 10 minutes.

I tried it on my 10.1 clean default install on a Parallels. The machin Parallels runs on has already a CPU load of about 80% (video editing) This is my output: (First time) linux-y03a:~ # time rug sl Waking up ZMD...Done # | Status | Type | Name | URI --+--------+------+--------------------------------------------------------+------------------------------------------------------------------------------------- 1 | Active | ZYPP | SUSE-Linux-10.1-CD-download-x86-10.1-0-20060518-055222 | cd:///?devices=/dev/hdb&alias=SUSE-Linux-10.1-CD-download-x86-10.1-0-20060518-055222 2 | Active | ZYPP | SUSE-Linux-10.1-Updates | http://fr.rpmfind.net/linux/SuSE-Linux/update/10.1/ real 1m42.804s user 0m0.464s sys 0m1.076s (Second time) linux-y03a:~ # time rug sl # | Status | Type | Name | URI --+--------+------+--------------------------------------------------------+------------------------------------------------------------------------------------- 1 | Active | ZYPP | SUSE-Linux-10.1-CD-download-x86-10.1-0-20060518-055222 | cd:///?devices=/dev/hdb&alias=SUSE-Linux-10.1-CD-download-x86-10.1-0-20060518-055222 2 | Active | ZYPP | SUSE-Linux-10.1-Updates | http://fr.rpmfind.net/linux/SuSE-Linux/update/10.1/ real 0m2.256s user 0m0.832s sys 0m0.668s (First time after the above) linux-y03a:~ # time rug ca Sub'd? | Name | Service -------+--------------------------------------------------------+------------------------------------------------------- Yes | SUSE-Linux-10.1-Updates | SUSE-Linux-10.1-Updates Yes | SUSE-Linux-10.1-CD-download-x86-10.1-0-20060518-055222 | SUSE-Linux-10.1-CD-download-x86-10.1-0-20060518-055222 real 0m1.377s user 0m0.380s sys 0m0.912s After a reboot I get the following times for `rug sl` real 0m1.716s user 0m0.380s sys 0m1.124s I must say, it would be nice to have the output not on such long lines. Even with my terminal on 1280x1024 I am not able to see the lines on one line. Makes it a lot harder to read. On my 1600x1200 I can read it. e.g.: # | Status | Type | Name --+--------+------+-------------------------------------------------------- 1 | Active | ZYPP | SUSE-Linux-10.1-CD-download-x86-10.1-0-20060518-055222 | URI | cd:///?devices=/dev/hdb&alias=SUSE-Linux-10.1-CD-download-x86-10.1-0-20060518-055222 2 | Active | ZYPP | SUSE-Linux-10.1-Updates | URI | http://fr.rpmfind.net/linux/SuSE-Linux/update/10.1/ Or # | Status | Type | Name --+--------+------+-------------------------------------------------------- 1 | Active | ZYPP | SUSE-Linux-10.1-CD-download-x86-10.1-0-20060518-055222 | URI | cd:///?devices=/dev/hdb&alias=SUSE-Linux-10.1-CD-download-x86-10.1-0-20060518-055222 --+--------+------+-------------------------------------------------------- 2 | Active | ZYPP | SUSE-Linux-10.1-Updates | URI | http://fr.rpmfind.net/linux/SuSE-Linux/update/10.1/ -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

On Tuesday 23 May 2006 12:24, Anders Norrbring wrote:

Apparently it's the wake-up of Zen that takes forever.. Yeah: AMD64 3200+, 1GB RAM:

Waking up ZMD takes minutes (4 minutes ) and the top processes are parse-metadata and gpg: - gpg something like: gpg --no-default-keyring --quiet --no-tty --no-greeting --no-permission-warning --status-fd 1 --homedir /var/tmp/TmpDir.9ivB2c --import /var/lib/zypp/cache/Source.aDBK1K/DATA/content.key - parse-metadata is: I *did not* used an FTP source and when I started "rlug sl" my internet connection was down (dial-up...): rug sl Waking up ZMD...Done # | Status | Type | Name | URI --+--------+------+-----------------------------------------------------------+--------------------------------------------------------------------------------------- 1 | Active | ZYPP | SUSE-Linux-CD-OSS-x86_64-10.1-0-20060414-082827 | cd:///?devices=/dev/hdc,/dev/hdd;alias=SUSE-Linux-CD-OSS-x86_64-10.1-0-20060414-082827 2 | Active | ZYPP | SUSE-Linux-add-on-CD-10.1-0-20060423-180936 | cd:///?devices=/dev/hdc,/dev/hdd;alias=SUSE-Linux-add-on-CD-10.1-0-20060423-180936 3 | Active | ZYPP | 20060516-193554 | ftp://ftp.iasi.roedu.net/mirrors/ftp.suse.com/pub/suse/update/10.1 4 | Active | ZYPP | SUSE-Linux-10.1-Updates | ftp://ftp.suse.com/pub/suse/update/10.1/ 5 | Active | ZYPP | SUSE-Linux-10.1-CD-download-x86_64-10.1-0-20060517-172513 | dvd:///?alias=SUSE-Linux-10.1-CD-download-x86_64-10.1-0-20060517-172513 6 | Active | ZYPP | 20060517-180334 Before you tell me about the dups, in Yast Installation Sources (which again takes quite some time to show up completely) I have the following: On Off SUSE Linux 10.1 dvd:/// Off On YUM ftp://ftp.iasi.roedu.net/mirrors/ftp.suse.com/pub/suse/update/10.1 On On YUM dir:///media/extra/data/data/opensuse/packman/10.1 On On YUM ftp://ftp.suse.com/pub/suse/update/10.1 The first update was added manually, while during registration it added the last one (it failed to detect a mirror for me). So in this case it cannot be about downloading a huge XML file or something like that. rug ca Sub'd? | Name | Service -------+-----------------------------------------------------------+---------------------------------------------------------- | SUSE-Linux-CD-OSS-x86_64-10.1-0-20060414-082827 | SUSE-Linux-CD-OSS-x86_64-10.1-0-20060414-082827 | SUSE-Linux-add-on-CD-10.1-0-20060423-180936 | SUSE-Linux-add-on-CD-10.1-0-20060423-180936 Yes | 20060516-193554 | 20060516-193554 Yes | 20060517-180334 | 20060517-180334 Yes | SUSE-Linux-10.1-CD-download-x86_64-10.1-0-20060517-172513 | SUSE-Linux-10.1-CD-download-x86_64-10.1-0-20060517-172513 Yes | SUSE-Linux-10.1-Updates | SUSE-Linux-10.1-Updates The system is an update from 10.0 in several steps through some beta's and RC's. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org

Hi,

/usr/lib64/zmd/parse-metadata /var/lib/zmd/zmd.db zypp

[...]

/usr/lib64/zmd/parse-metadata /var/lib/zmd/zmd.db zypp

Why does this executable live in /usr/lib64? How can zmd.exe find it there? Is it compiled differently on lib64 systems? But wasn't it supposed to be architecture independent? Sounds like another bug... Andreas Hanke -- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer

Hi,

SUSE uses lib64 for default 64bit libraries, so on AMD64 "everything" is is /usr/lib64.

parse-metadata is not a library.

...

Sounds like another bug...

I don't think so.

But I do. I just had a quick look and it looks like zmd.exe is really compiled differently on i586 and x86_64. It shouldn't be, and the executables shouldn't be in the lib64 directory. But it's probably not worth a bug report because the zmd package as a whole (not zmd.exe) needs to be architecture specific anyway for other, unrelated reasons. Andreas Hanke -- Bis zu 70% Ihrer Onlinekosten sparen: GMX SmartSurfer! Kostenlos downloaden: http://www.gmx.net/de/go/smartsurfer

Andras Mantia writes:

On Tuesday 23 May 2006 12:24, Anders Norrbring wrote:

...

Apparently it's the wake-up of Zen that takes forever.. Yeah: AMD64 3200+, 1GB RAM:

Waking up ZMD takes minutes (4 minutes ) and the top processes are parse-metadata and gpg:

- gpg something like: gpg --no-default-keyring --quiet --no-tty --no-greeting --no-permission-warning --status-fd 1 --homedir /var/tmp/TmpDir.9ivB2c --import /var/lib/zypp/cache/Source.aDBK1K/DATA/content.key

- parse-metadata is:

I *did not* used an FTP source and when I started "rlug sl" my internet connection was down (dial-up...):

zmd does not store everything, so for every wakeup we have to parse the xml data. This still takes a long time :-(

rug sl Waking up ZMD...Done

# | Status | Type | Name | URI --+--------+------+-----------------------------------------------------------+--------------------------------------------------------------------------------------- 1 | Active | ZYPP | SUSE-Linux-CD-OSS-x86_64-10.1-0-20060414-082827 | cd:///?devices=/dev/hdc,/dev/hdd;alias=SUSE-Linux-CD-OSS-x86_64-10.1-0-20060414-082827 2 | Active | ZYPP | SUSE-Linux-add-on-CD-10.1-0-20060423-180936 | cd:///?devices=/dev/hdc,/dev/hdd;alias=SUSE-Linux-add-on-CD-10.1-0-20060423-180936 3 | Active | ZYPP | 20060516-193554 | ftp://ftp.iasi.roedu.net/mirrors/ftp.suse.com/pub/suse/update/10.1 4 | Active | ZYPP | SUSE-Linux-10.1-Updates | ftp://ftp.suse.com/pub/suse/update/10.1/ 5 | Active | ZYPP | SUSE-Linux-10.1-CD-download-x86_64-10.1-0-20060517-172513 | dvd:///?alias=SUSE-Linux-10.1-CD-download-x86_64-10.1-0-20060517-172513 6 | Active | ZYPP | 20060517-180334

Before you tell me about the dups, in Yast Installation Sources (which again takes quite some time to show up completely) I have the following: On Off SUSE Linux 10.1 dvd:/// Off On YUM ftp://ftp.iasi.roedu.net/mirrors/ftp.suse.com/pub/suse/update/10.1 On On YUM dir:///media/extra/data/data/opensuse/packman/10.1 On On YUM ftp://ftp.suse.com/pub/suse/update/10.1

The first update was added manually, while during registration it added the last one (it failed to detect a mirror for me). So in this case it cannot be about downloading a huge XML file or something like that.

So, remove the dups to speed up...

The system is an update from 10.0 in several steps through some beta's and RC's.

We have to handle that better, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On Wednesday 24 May 2006 16:32, Andras Mantia wrote:

How can I do it? I see no dups in GUI so if you suggest that I should use a command line tool, there is a problem for the regular end user...

After removing the duplicates, upgrading the rpm, restarting zmd and waiting a little: time rug sl Waking up ZMD...Done # | Status | Type | Name | URI --+--------+------+-----------------------------------------------------------+------------------------------------------------------------------------ 1 | Active | ZYPP | 20060516-193554 | ftp://ftp.iasi.roedu.net/mirrors/ftp.suse.com/pub/suse/update/10.1 2 | Active | ZYPP | SUSE-Linux-10.1-CD-download-x86_64-10.1-0-20060517-172513 | dvd:///?alias=SUSE-Linux-10.1-CD-download-x86_64-10.1-0-20060517-172513 3 | Active | ZYPP | 20060517-180334 | dir:///media/extra/data/data/opensuse/packman/10.1/ real 3m13.341s user 0m0.484s sys 0m0.008s This is better, but I'm not sure if not the removal of duplicates helped. The new one seems to be slow as the old one. Andras Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org

houghi wrote:

On Wed, May 24, 2006 at 03:05:56PM +0200, Andreas Jaeger wrote:

...

zmd does not store everything, so for every wakeup we have to parse the xml data. This still takes a long time :-(

Having a crontab every 20 minutes seems to do the trick Just keep it awake. I do not know what the concequences are and it seems to be an extremely ugly trick, I think.

I wonder if anyone has come up with any problems with houghi's workaround? Or any other workaroud? When ZMD has gone asleep: time rug sl Waking up ZMD...Done # | Status | Type | Name | URI --+--------+------+-------------------------------------------------+----------- 1 | Active | ZYPP | SUSE-Linux-10.1-DVD-i386-10.1-0-20060524-035909 | ftp://1... 2 | Active | ZYPP | SUSE-Linux-10.1-Updates | http://... 3 | Active | YUM | packman | http://... 4 | Active | ZYPP | guru | ftp://f... real 13m58.045s user 0m1.744s sys 0m0.164s That's 14 minutes, can hardly wait! Then within his time awake: time rug sl # | Status | Type | Name | URI --+--------+------+-------------------------------------------------+----------- 1 | Active | ZYPP | SUSE-Linux-10.1-DVD-i386-10.1-0-20060524-035909 | ftp://1... 2 | Active | ZYPP | SUSE-Linux-10.1-Updates | http://... 3 | Active | YUM | packman | http://... 4 | Active | ZYPP | guru | ftp://f... real 0m1.989s user 0m1.632s sys 0m0.128s As houghi's solution keeps him awake, it seems like a cure for the time being or what? Vahis -- Sometimes I answer to top posters. Once. http://waxborg.servepics.com/English/Linux/SUSE.10.1/suse10.1.html SUSE Linux 10.1 Suomi: http://waxborg.servepics.com/Linux/10.1/suse-10.1.html

On Sat, May 27, 2006 at 04:05:18PM +0200, Andreas Jaeger wrote:

Edit /etc/zmd/zmd.conf and change the sleep-interval: [Server] sleep-interval=1800

Change 1800 to something larger...

Is there a maximum? Are there disadvantages if you use an extreme large sleep-interval? e.g. what happens if you do a sleepinterval of 24 hours and then use crontab to do a forced update at a moment where it does not matter, like at 04:00 or whenever you least likely are going to use it. One disadvatages I can imagine on the top of my head are unneeded load on the servers. What if you make the timeout a week, or a month, or indefinite? -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

Andreas Jaeger wrote:

Vahis writes:

...

houghi wrote:

...

On Wed, May 24, 2006 at 03:05:56PM +0200, Andreas Jaeger wrote:

...

zmd does not store everything, so for every wakeup we have to parse the xml data. This still takes a long time :-(

Having a crontab every 20 minutes seems to do the trick Just keep it awake. I do not know what the concequences are and it seems to be an extremely ugly trick, I think.

I wonder if anyone has come up with any problems with houghi's workaround? Or any other workaroud?

Edit /etc/zmd/zmd.conf and change the sleep-interval: [Server] sleep-interval=1800

Change 1800 to something larger...

Andreas

But doesn't this only make him go to sleep more seldom? The next time I need him he's asleep again anyway.. I'd need him to be awake, fresh and ready when I need him. Houghi's solution obviously would do that, but as he said, it's processor load and server traffic in vain. I have had refresh on in all my YaST sources in 10.0, so I know it takes a lot of time to refresh, so maybe it's just the same here. When I know I'm going to need zmd, I'll ask him to wake up and go do something else for a while. In case I forget him for a too long time, I think what Andreas says will prevent him from going to sleep again too soon. Vahis -- Sometimes I answer to top posters. Once. http://waxborg.servepics.com/English/Linux/SUSE.10.1/suse10.1.html SUSE Linux 10.1 Suomi: http://waxborg.servepics.com/Linux/10.1/suse-10.1.html

Andreas Jaeger wrote:

Frank-Michael,

have you done an update from a previous beta/RC on these machines?

What's the output of: * rug sl * rug ca

Andreas

Now this is interesting: After reinstalling rug, running "rug sl" & "rug ca" and rebooting the system, bug 177758 does not show anymore. Could it be that everyone who started "rug" at least once explicitely or implicitely gets rid of the bug? FMF

jdd wrote:

rug starting ZEN updater... (waiting...)

no, it was "rug cc" that did this and no more and I have "update-status" thats keep 99% cpu (but the computer is still alive :-) jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

Hello, Frank-Michael Fischer wrote:

These are three machines showing this bug: 2GHz/512MB, 2.2GHz/512MB and 2.8GHz/1GB. Older, slow machines?

The reports I read on Hungarian lists were about P3's and early P4 machines without much RAM. These were running 9.X and even 10.0 well, but have trouble with 10.1. Personally I only have experience with 1.9Ghz PentiumM with 512MB of RAM (Compaq nx8220) and dual 2.4Ghz P4 Xeons with 2-3GB of RAM (IBM IntelliStations), neither of these showed any significant slow down. On my 1Ghz PPC machine with 256MB of RAM I can feel some slow down, but only beagle has a real impact on performance, which I don't use anyway. Now I just kill it, I did not even take time to delete it :-) I still use plain & old updatedb, which does not have any impact on the same machine. Bye, -- CzP http://peter.czanik.hu/

On Tue, May 23, 2006 at 10:03:16AM +0200, Frank-Michael Fischer wrote:

Ofcourse, that's what I am doing. But I could also build linux from scratch then. The moment, Novell decides to drop "zmd rug zen-updater" from the default installation I can recommend this distro again. Why?

Don't hold your breath for that. What I expect is that in 10.2 these issues will be solved one way or another. Yes, it should not have gotten into 10.1, but into 10.2. It has not and it has been explained why as well. So can we go on with it and stop moaning how much everybody hates it? -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

Frank-Michael Fischer writes:

Problem is: during beta test I have been busy reporting and detailling other bugs so I did not participate in the zen buddism here. And I'd agree with you that it will be solved etc. I just did not know (did you?) that it takes up to half an hour to get a 2.xGHz machine booted into a proper functioning state. For me this order of magnitude of slow down is unexpected, I am not even sure it was there with beta versions.

It's unexpected for me as well, I wouldn't have shipped it if we had seen this with new installation. I got some reports from people doing an update from Beta7 where zmd took ages and those where a result of old repositories. Btw. I'm currently working on releasing an update of the package management stack. It will not solve the performance issues in general but fixes a couple of bugs so if the problem you have comes from such a bug, it might be fixed... Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Tom Horsley skrev:

On Tue, 2006-05-23 at 10:17 +0200, Frank-Michael Fischer wrote:

...

Problem is: during beta test I have been busy reporting and detailling other bugs so I did not participate in the zen buddism here.

Real problem is that during beta testing there were no $#@! update servers available for testing, just a new beta every week, so none of the Zen stuff (practically the only reason for the 10.1 release) ever got any testing.

My guess as to why some people have problems and others don't: Bad connectivity to the update server that got picked for the system. Try poking around on the mirrors list and selecting different ones manually.

Nope, I don't think it is.. I have huge delays even on a local mirror on Gbit networking... Anders.

On Tue, May 23, 2006 at 05:55:18AM -0400, Tom Horsley wrote:

Real problem is that during beta testing there were no $#@! update servers available for testing, just a new beta every week, so none of the Zen stuff (practically the only reason for the 10.1 release) ever got any testing.

It would be indeed helpfull if there would be an update directory available on factory. This directory does not need to have any security rpms, but to test updates, some RPM's and scripts and whatever would be nice. "Changes" can be done to just textfiles, like the 'Release Notes' and the like. Just one of each type of update that is possible. (complete RPM, delta RPM, script, ...) That way we can test the concept and see what happens. -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

Frank-Michael Fischer wrote:

It blocks my three 10.1 systems always at bootup and never for less than 20 minutes. These are all installations from scratch.

note that thousand of SUSE Linux 10.1 users _don't_ have this problem. so may be you could try to understant what goes wrong, as it may be possible than one of your prefered setup may just conflict with the default settings. I think if the problem was as hard as you say for anybody, we should already know. so why flame? please, slowdown and try to find the real problem. jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

Frank-Michael Fischer writes:

And I found the real problem: it's the way libzypp is architected and implemented. Now what?

Let's discuss this next week - the main architect is travelling this week and I want to have him in the discussion... I'm very interested in your findings - and what you and others think can be changed for 10.2, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Frank-Michael Fischer writes:

Thanks a lot, I will watch for these fixes. And I am available for such discussions. Meanwhile I did reinstall rug (just 4u ;-) What do you mean by:

* rug sl * rug ca

I never used rug before so I wouldn't know how to interpret your mnemonics.

Those are commands that you can run, on my system, "sl" is the same as "service-list", and "ca" as "catalogs", they show the installation sources in your system. On my test system right now: tux@d62:~> rug sl # | Status | Type | Name | URI --+--------+------+--------------------------------------------------------+--------------------------------------------------------------------------------------------------------------------------- 1 | Active | ZYPP | SUSE-Linux-10.1-DVD9-x86-x86_64-10.1-0-20060522-041628 | ftp://10.10.0.100/%2finstall/SLP/SUSE-10.1-DVD9-RC5/i386/DVD1?alias=SUSE-Linux-10.1-DVD9-x86-x86_64-10.1-0-20060522-041628 2 | Active | ZYPP | SUSE-Linux-10.1-Updates | http://ftp.leo.org/pub/comp/os/unix/linux/suse/suse/update/10.1/ tux@d62:~> rug ca Sub'd? | Name | Service -------+--------------------------------------------------------+------------------------------------------------------- Yes | SUSE-Linux-10.1-Updates | SUSE-Linux-10.1-Updates Yes | SUSE-Linux-10.1-DVD9-x86-x86_64-10.1-0-20060522-041628 | SUSE-Linux-10.1-DVD9-x86-x86_64-10.1-0-20060522-041628 Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

jdd wrote:

this don't mean you do anything wrong, only something that not any people do. identifying this could be of great help like the rug test you where asked to do.

and all this helps fixing the bug.

done FMF

jdd wrote:

jdd wrote:

...

I will try the "lanch on start and see is this slows the starting)

no slowing down at all...

almost instant result for:

jdd@peter:~> rug sl

# | État | Type | Nom | URI --+--------+------+--------------------------------------------------------+------------------------------------------------------------------------------------------------------------------------------

1 | Active | ZYPP | SUSE-Linux-CD-OSS-i386-10.1-0-20060430-120239 | dir:///media/usb_linux/factory/rc3?alias=SUSE-Linux-CD-OSS-i386-10.1-0-20060430-120239

2 | Active | ZYPP | SUSE-Linux-CD-OSS-i386-10.1-0-20060430-164930 | cd:///?alias=SUSE-Linux-CD-OSS-i386-10.1-0-20060430-164930 3 | Active | ZYPP | SUSE-Linux-CD-OSS-i386-10.1-0-20060430-185800 | dir:///media/usb_linux/factory/rc3?alias=SUSE-Linux-CD-OSS-i386-10.1-0-20060430-185800

4 | Active | ZYPP | SUSE-Linux-10.1-CD-download-x86-10.1-0-20060511-135302 | cd:///?devices=/dev/hdc&alias=SUSE-Linux-10.1-CD-download-x86-10.1-0-20060511-135302

5 | Active | ZYPP | SUSE-Linux-10.1-FTP-10.1-0-20060515-174254 | http://download.opensuse.org//distribution/SL-10.1/inst-source/?alias=SUSE-L...

6 | Active | ZYPP | SUSE-Linux-10.1-FTP-EXTRA-10.1-0-20060515-174815 | http://download.opensuse.org/distribution/SL-10.1/non-oss-inst-source/?alias...

7 | Active | ZYPP | SUSE-Linux-10.1-CD-download-x86-10.1-0-20060515-181442 | dvd:///?alias=SUSE-Linux-10.1-CD-download-x86-10.1-0-20060515-181442 8 | Active | ZYPP | SUSE-Linux-10.1-Updates | http://gd.tuwien.ac.at/linux/suse.com/suse/update/10.1/ 9 | Active | ZYPP | 20060518-144808 | http://packman.iu-bremen.de/suse/10.1

jdd@peter:~> rug ca

Abonné ? | Nom | Service ---------+--------------------------------------------------------+-------------------------------------------------------

Oui | SUSE-Linux-CD-OSS-i386-10.1-0-20060430-164930 | SUSE-Linux-CD-OSS-i386-10.1-0-20060430-164930 Oui | SUSE-Linux-CD-OSS-i386-10.1-0-20060430-120239 | SUSE-Linux-CD-OSS-i386-10.1-0-20060430-120239 Oui | SUSE-Linux-CD-OSS-i386-10.1-0-20060430-185800 | SUSE-Linux-CD-OSS-i386-10.1-0-20060430-185800 Oui | SUSE-Linux-10.1-FTP-EXTRA-10.1-0-20060515-174815 | SUSE-Linux-10.1-FTP-EXTRA-10.1-0-20060515-174815 | SUSE-Linux-10.1-Updates | SUSE-Linux-10.1-Updates Oui | 20060518-144808 | 20060518-144808 Oui | SUSE-Linux-10.1-CD-download-x86-10.1-0-20060511-135302 | SUSE-Linux-10.1-CD-download-x86-10.1-0-20060511-135302 Oui | SUSE-Linux-10.1-CD-download-x86-10.1-0-20060515-181442 | SUSE-Linux-10.1-CD-download-x86-10.1-0-20060515-181442 Oui | SUSE-Linux-10.1-FTP-10.1-0-20060515-174254 | SUSE-Linux-10.1-FTP-10.1-0-20060515-174254

jdd@peter:~>

My first "rug sl" command took about 8 mins to complete. The next one was lightening fast. FMF

jdd wrote:

Frank-Michael Fischer wrote:

...

My first "rug sl" command took about 8 mins to complete. The next one was lightening fast.

is this true through reboots? that is, is that the first run of the session or the first run at all that is long?

in the first case, something goes wrong in the start mechanism, in the second there is a cache somewhere.

I experiment mostly slowdown problem with DHCP.

It lasts through reboots. So seems only the very first "rug" in the lifetime of an installation takes that long. FMF

On 23 May 2006 at 13:30, Andreas Jaeger wrote:

Frank-Michael Fischer writes:

...

My first "rug sl" command took about 8 mins to complete. The next one was lightening fast.

Yes, it needs to parse all the stuff and then the daemon has everything loaded.

Into RAM? If so, wouldn't it preferrable to use some light-weight & fast database library like Sleepycat (now: Oracle) to store meta-data instead of XML (on disk)? That way, the data structure would be ready almost immediately. I could imagine either shipping the metadata database as CD image, or as an "importable" database dump. I can imagine (juast a wild guess) that even BerkeleyDB mounted over NFS isn't much slower than XML-parsing the same data after downloading them. (If you are asking about incremental updates)

8 minutes is still to long and therefore I would like to see which repositories you use (output of "rug sl") to get a feeling whether there's a reason for it. It needs roughly two minutes on my system,

How much virtual memory does it need then? >512MB? Regards, Ulrich

jdd wrote:

Frank-Michael Fischer wrote:

...

So: I am well trained in taking comments like yours.

can't you beleive most users have _not_ the problem you have?

Can't *you* believe *many* users do have that problem ? Again, come hang around on IRC and witness the havoc.

I have a default kde install, and had some kind of bugs, but _not_ the one you have.

You're part of the lucky ones, I would say. ...

...

And I found the real problem: it's the way libzypp is architected and implemented. Now what?

Actually I don't think it's libzypp, it's more about ZMD. Could someone post a few details about what libzypp actually does and how it interacts with ZMD ? Is it an abstraction and/or API to ZMD and rug ? Is libzypp the one capable of handling yast2/ZMD repos and RPM-MD ? Or is it ZMD/rug ? When using RPM-MD repos in yast2, does it still go through ZMD ? [...]

what I try to make you understant is that if _you_ have _several_ non working install, this may be because you always make a kind of install that gives the problem.

That ridiculous. What would some "kind of install" have to do with ZMD working properly or not on 3 different boxes and several others he did from scratch. And he's not alone with this issue, it's being reported often on IRC. On IRC we currently recommend using smart, y2pmsh or rug and disable+remove ZMD packages.

this don't mean you do anything wrong, only something that not any people do. identifying this could be of great help like the rug test you where asked to do.

Well, I strongly presume those problems are related to plain ZMD and/or libzypp bugs, not particularly to his setup. Those problems are encountered far too often to just be related to some specifics of his installation or hardware.

and all this helps fixing the bug. and by the way the starting of the 10.1 is specially fast on my two years old machine... and I just discovered beagle was running.. I even don't know what it is :-) [...] to follow this mail, I tryed beagle. clic on the icon, ask for "yast" in the search box. Beagle said the daemon was not started, I clic to start and answers come is nearly no time.

Yes, the Beagle frontends work well, no problem with that. But the Beagle daemon is also often a resource hog that causes people on IRC to complain about 10.1 being so slow. I suppose there's not all that much to be done about the Beagle daemon, it's kind of inherent to what it does (it has to do a lot of I/O and probably actually needs a lot of memory) - document indexers usually do that, I don't think there's a silver bullet to solve it. Nevertheless, Beagle is not a critical component to the system. If it's a resource hog on your system, then just turn it off, SUSE Linux 10.1 will remain an excellent distribution to work with. The same cannot be said of the package management subsystem. The latter must work reliably, always, so we really have to identify and fix bugs there (and not dismiss them). cheers -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v http://www.fosdem.org

Pascal Bleser wrote:

Can't *you* believe *many* users do have that problem ? Again, come hang around on IRC and witness the havoc.

...

...

And I found the real problem: it's the way libzypp is architected and implemented. Now what?

Actually I don't think it's libzypp, it's more about ZMD.

Could someone post a few details about what libzypp actually does and how it interacts with ZMD ? Is it an abstraction and/or API to ZMD and rug ?

Is libzypp the one capable of handling yast2/ZMD repos and RPM-MD ? Or is it ZMD/rug ?

When using RPM-MD repos in yast2, does it still go through ZMD ?

[

The reason why I am assuming it's libzypp's fault is: when I filed the bug it was for the Zen component, then Nat Budin changed the component to libzypp and connected this bug with bug 176301. This bug I am not supposed to view. So it's fair to guess there is something rotten in the state of libzypp. And we should not participate, just sit and wait. After playing around with this problem a bit it seems likely that running "rug sl" just once is the workaround for this bug. FMF

Frank-Michael Fischer writes:

The reason why I am assuming it's libzypp's fault is: when I filed the bug it was for the Zen component, then Nat Budin changed the component to libzypp and connected this bug with bug 176301. This bug I am not supposed to view. So it's fair to guess there is something rotten in the state of libzypp. And we should not participate, just sit and wait.

Why is everybody thinking there's something rotten going on if a bug is closed? The bug is "Bug 176301 - Overview bug for performance issues regarding zypp, zlm, NCC" and starts with: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ We have identified some bugs which all have some influence to the performance issues. NONE of this is a blocker for itself, but alltogether results in the performance we face now. I opened this bug with severity blocker to keep track of all the issues. If we could fix some/most of the related bugs, we could downgrade this one to critical or even major. Currently I am aware of #155591, #163186, #169719, #175880, #174887 If any one is aware of further bugs related to perfomarnce add the to the dependency tree of this one. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ And the developers add any bugreport that they thing is performance related. Nothing more. The initial report was against SLES10 which is closed and therefore the bug is closed. But their's no conspiracy or whatever.

After playing around with this problem a bit it seems likely that running "rug sl" just once is the workaround for this bug.

Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

houghi writes:

On Tue, May 23, 2006 at 01:38:56PM +0200, Andreas Jaeger wrote:

...

Frank-Michael Fischer writes:

...

The reason why I am assuming it's libzypp's fault is: when I filed the bug it was for the Zen component, then Nat Budin changed the component to libzypp and connected this bug with bug 176301. This bug I am not supposed to view. So it's fair to guess there is something rotten in the state of libzypp. And we should not participate, just sit and wait.

Why is everybody thinking there's something rotten going on if a bug is closed?

I believe you misread it. The bug was moved. Because it was originaly was reported as a lybzypp bug, the one where it is moved to will also be a libzypp bug.

I'm talking about 176301. It was never public. Let's leave that one as reported against SLES - that way it will get highest priority ;-). If anybody likes to be CC'ed on it, tell me offline and I add you to it.

This most likely means that there is an issue with libzypp, because otherwise the bug would have been closed and not noted as a duplicate.

Bug 177758 was connected to 176301 as "bug 177758 must be first fixed before we can close 176301".

All is giuessing, because we are not allowed to see #176301 even though it was first a public one.

It never was.

So the conclusion of Frank-Michael is correct: It must be a libzypp issue.

Those are totally unrelated - but since 176301 is not public, you can just speculate ;-) Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On Tue, May 23, 2006 at 02:12:28PM +0200, jdd wrote:

so one could not know what is said, but could now that somebody works on it.

Why? As long as it is not solved, somebody is working on it. -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

jdd skrev:

houghi wrote:

...

On Tue, May 23, 2006 at 02:12:28PM +0200, jdd wrote:

...

so one could not know what is said, but could now that somebody works on it.

Why? As long as it is not solved, somebody is working on it. or sleeping on it :-) jdd

You mean like zmd? :) Anders.

On Tue, May 23, 2006 at 02:06:27PM +0200, Andreas Jaeger wrote:

Those are totally unrelated - but since 176301 is not public, you can just speculate ;-)

Indeed and that is what we are doing. I did not ment to say that 176301 was public. The original was public and then was moved onto 176301 and was labeld libzypp. Also I see the 'rotten' as a wink to Shakespears "There is something rotten in the state of Denmark' :-) -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

houghi wrote:

So the conclusion of Frank-Michael is correct: It must be a libzypp issue.

If I follow well the thread it seems this is a meta-data download problem. anyway, could it be possible to have * a guess of the dowloading time * a way to stop this (I don't know for 10.1, but on 10.0 clickin,g stop didn't stop anything) and a background upgrade should be nice (cron?). jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

Ulrich Windl wrote:

On 23 May 2006 at 14:09, jdd wrote:

...

If I follow well the thread it seems this is a meta-data download problem.

If it's a download problem, why would the CPU be at 100%?

Regards,

Thanks for your support! I started to get confused already. FMF

Ulrich Windl wrote:

On 23 May 2006 at 14:09, jdd wrote:

...

If I follow well the thread it seems this is a meta-data download problem.

If it's a download problem, why would the CPU be at 100%?

That sounds a lot like XML repository metadata parsing. libzypp/ZMD is most probably not parsing the data stream as it is being downloaded, so I presume it's download everything (for one repository) first, then parse. Would be interesting to do some profiling on parse-metadata. Anything available for Mono ? What XML parsing model is being used there, SAX, DOM, StAX ? Most probably not DOM... When I look at my ("guru") RPM-MD repository for 10.0 (which is large, but a lot smaller than the FTP tree): == compressed: primary.xml.gz = 1,058,326 (bytes) filelists.xml.gz = 1,029,756 other.xml.gz = 497,642 == uncompressed: primary.xml = 6,174,750 filelists.xml = 11,032,393 other.xml = 2,950,989 == compression ratio: primary.xml = 5.83 filelists.xml = 10.42 other.xml = 5.92 Now when I look at SL-10.1/inst-source/suse/repodata: == compressed: primary.xml.gz = 8,056,136 (bytes) filelists.xml.gz = 17,474,199 other.xml.gz = 53,265,854 BTW, other.xml.gz is *huge* (contains %changelog information) - I don't know whether libzypp/zmd download and/or use "other.xml.gz" though. smart (http://smartpm.org) doesn't. == uncompressed: primary.xml = 47,127,500 filelists.xml = 211,884,423 other.xml = 206,534,422 == compression ratio: primary.xml = 5.83 filelists.xml = 12.12 other.xml = 3.87 Assuming that other.xml is not being used by libzypp/ZMD, I would guess the following memory usage with DOM: - primary.xml: 47MB on disk => 150-200MB RAM - filelists.xml: 210MB on disk => 600-800MB RAM Hmm.. after all... maybe it _is_ DOM ;) Could someone with the mentioned libzypp/ZMD problems have a look at memory/swap usage as well ? - vmstat -n 5 999 - sar -r 5 999 (even better; sar is part of the sysstat package)) The yast2 format is possibly more efficient wrt memory and CPU. Maybe worth investigating whether the memory+CPU problems happen with RPM-MD repos but not with yast2 repos... ? I'd say turn down (or even remove) all repositories, then just add the 10.1 FTP tree metadata, and run vmstat or sar to monitor CPU+memory usage. With sysstat, it can be done like this: sar -r -X `pidof parse-metadata` 5 999 (5 = 5 second interval, 999 = number of iterations) You can even draw graphs from that data when you store it into a file (-o option, it's a binary format), but you can't use -o in conjunction with -X, so the stats would be system-wide: mkdir ~/sar sar -o ~/sar/sa.$(date '+%Y_%m_%d') -r -u 5 999 isag -p ~/sar ... then choose the file (click on the "-" button) and choose memory or CPU graph (and you can even save the picture). cheers -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ _\_v http://www.fosdem.org http://opensuse.org

On 23 May 2006 at 18:39, Andreas Jaeger wrote: [...]

...

Would be interesting to do some profiling on parse-metadata. Anything available for Mono ?

parse-metadata is in C++. [...]

Hi, some time ago I was reflecting on how to boost performance on a Pentium Pro 200 MHz with 128MB RAM. I concluded that today's programming language and -style suffers from needless copying of data (not to talk about needless calling of code), making the relatively fast CPU cache quite useless. As a proof on concept I wrote a sample program that does very aggressive data sharing (kind of "copy on write"). The performance is really great (I did unpack MIME messages): It's about a factor of 1000 faster than PINE. However: Data inter-dependencies are terrible, and it's a maintenance pain. Performance sample (on a P4 2.8GHz meanwhile): base64-decoding 9219kB (includes reading the source (most likely cached, however) and writing the output): 0.161s (elapsed! time (wall time)) Now for XML... ;-) Regards, Ulrich

Andreas Jaeger wrote:

Frank-Michael Fischer writes:

...

The reason why I am assuming it's libzypp's fault is: when I filed the bug it was for the Zen component, then Nat Budin changed the component to libzypp and connected this bug with bug 176301. This bug I am not supposed to view. So it's fair to guess there is something rotten in the state of libzypp. And we should not participate, just sit and wait.

Why is everybody thinking there's something rotten going on if a bug is closed?

Not because it's closed. I could not even know that. It's because I am not supposed to know the bug. This creates the "rotten" suspicion. FMF

On Tue, May 23, 2006 at 02:07:00PM +0200, Andreas Jaeger wrote:

...

...

Why is everybody thinking there's something rotten going on if a bug is closed?

Not because it's closed. I could not even know that. It's because I am not supposed to know the bug. This creates the "rotten" suspicion.

"closed " was meant in the sense of "private"/"non-public",

Ah, as in 'source'. Now it is much clearer. -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

Frank-Michael Fischer wrote:

The reason why I am assuming it's libzypp's fault is: when I filed the bug it was for the Zen component, then Nat Budin changed the component to libzypp and connected this bug with bug 176301. This bug I am not supposed to view. So it's fair to guess there is something rotten in the state of libzypp. And we should not participate, just sit and wait.

there is a real bug, it is the visible/invisible state of a bug in bugzilla. We already discuss this here, no real solution I fear :-(

After playing around with this problem a bit it seems likely that running "rug sl" just once is the workaround for this bug.

yes and no. during my tests I've seen zen sessions shadowwed several times. may be there is a problem is this corner, when creating the first run config. is not, if this is necessary, it should run with a better nice to not stop the computer running... Most applications are longer to run at first launch (look at Gimp), but none should freeze your computer jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

tirsdag 23 maj 2006 12:33 skrev Pascal Bleser:

jdd wrote:

...

can't you beleive most users have _not_ the problem you have?

Can't *you* believe *many* users do have that problem ? Again, come hang around on IRC and witness the havoc.

I experience the same thing as Frank - on my 900mhz/512 mb laptop - I added inst-source, non-oss, packman, guru and kde-update to yast installation sources module. After every boot the processes "parse-metadata" and "update-status" use up a lot cpu for *at least* half an hour. Same thing happens if I should want to run the Zen Software Installer. On my AMD64 3000+/1 gig ram work station things weren't nearly as bad - but still very slow. Of course I quickly solved this by removing all repos from zen/rug - that way there is not much update status to check and no metadata for it to parse. And then installing Smart in stead. The only reason I didn't remove rug/zen entirely is that I want to be able to test it some more and give feedback. Good to hear AJ's interest in our feedback. I've been meaning to do a list that describes everything about Zen/rug/Yast/zmd/libzypp that I don't like. Since AJ suggested a discussions about this next week I'll start preparing :) Actually I generally like the "setup" - with the three frontends. Rug for cli, Zen for the random quick install and Joe sixpack users - and YaST if you want/need a lot of options and information. If only it would work - and preferably pretty fast at that - it would be nice. However I can't help but wonder how things would look if the ressources that were put into the whole libzypp-, rug-, zenworks-thing had been invested in developing Smart instead.. I've only used Smart for about a week and primarily the gui - but I'm absolutely blown away - to have YaST-qt as a frontend for that would rock the world I think. I also tend to think that maybe it would be smarter (get it?) to ditch Zen and go with Smart - given the amount of work Zen still needs. Using Smart the last week or so actually gives food to the idea that "Not invented here" is playing a part in what's going on. Maybe it's true that Novell wants to reinvent everything in Mono. PS. Someone said, you lose the systray update notifier if you move to Smart. Not necessarily so - on the guru source there's a package called Ksmarttray - that does just that. Martin / cb400f

Henne Vogelsang wrote: (...)

This is bad but not unfixable.

I really like this kind of post. thanks jdd -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

tirsdag 23 maj 2006 14:11 skrev Henne Vogelsang:

Everything else is working pretty flawlesly. Can we agree on that?

This is bad but not unfixable.

Flawlessly? I'm sorry but we can't agree on that. Those are easily the most serious bugs - but there are a lot of smaller irritations - and though I'm not a developer or a genius I'm a pretty experienced SUSE user I think - what's irritating to me will be completely unacceptable and incomprehensible to most noobs. Here's a quick list of issues that bother me - some of which have already been fed to bugzilla in beta-state. * there are serious problems with: right click on rpm > Open with Software Installer / actions > Install package with YaST * you can't add a simple directory containing rpms as a source to yast - which was never a problem before * YaST gives no information when it's downloading or refreshing repodata making inexperienced users think it's frozen. For inspiration on how to handle this I would look at the smart -gui which tells you what's downloaded, how much, from where, at what speed etc. * The issue with repos not being digitally signed. The warning message keeps popping up - no matter how many times you tell it "don't show this message agian". * Maybe this one is me being stupid - but if you have services added, but not subscribed to - it seems to me that zen/rug still parses metadata for those. And I've even had rug ask me for a cd when the cd catalog was unsubscribed and factory added and subscribed to (it was during betas, but it's not fixed yet). I thought that added / subscribed-unsubscribed were the equivalents to added/activated-deactivated in yast - but that's not the case apparently. * Also you can't seem to have more instances of packagemanagement running - don't know if this is intentional, and has to be this way. But it certainly was no problem to have "installation souces" and "software management" open at the same time in earlier releases, for example. * If you add sources to yast they're automatically added to zen/rug - but this doesn't work the other way around. I don't know what the long term strategy is - but if yast sw and zen are supposed to coexist in the long run I'd like some kind of central repo-management module in which you could add, remove, deactivate, refresh etc. all the repos, with selections for all frontends. I'll probably think of more as soon as I click send - but these are issues I could currently think of. Martin / cb400f

tirsdag 23 maj 2006 14:47 skrev Martin Schlander:

I'll probably think of more as soon as I click send - but these are issues I could currently think of.

As expected I thought of some more pretty big issuses, imho at least, shortly after sending the last mail. So I'll do some more "crying" as Henne calls it :) - I think it's constructive input for making it better though. * YaST2 now installs dependencies without consulting/warning the user first - it can be a bit surprising sometimes to see all kinds of packages being installed that you never selected. * Conflicts/deps need to be taken care of one by one, unlike before. Often you get a lot of problems with the same reason - which could be easily resolved in one or two clean swoops "in the good old days" of <=10.0. * When you add sources to yast they are always called "YUM", in ZMD they're given numbers for a name - the date + some random numbers I guess. Once you've added maybe 6 or 7 sources it gets pretty hard to keep track of which is which - and there's generally not room for the entire url. Maybe there's a way to edit the names that I'm not aware of. After writing down these issues and the ones before it's becoming apparent to me that almost all of these issues are with YaST2. Maybe things actually work pretty well with rug/zen - apart from the parse-metadata and update-status slowness. I'll add the above issues to the page Henne set up on the wiki. http://en.opensuse.org/Libzypp/Issues Martin / cb400f

On Tuesday 23 May 2006 13:47, Martin Schlander wrote:

* YaST gives no information when it's downloading or refreshing repodata making inexperienced users think it's frozen. For inspiration on how to handle this I would look at the smart -gui which tells you what's downloaded, how much, from where, at what speed etc.

Agreed. This is a huge show stopper for the new SUSE users that visit the IRC channels wonidering what is going on. At a rough estimate I'd say say that 95% of new users ( and there are many of them on a daily basis visit IRC and ask about this ) assume YAST has frozen/crashed on them when they try to add *any* online software repo, far less the main inst-sources. This is clearly unacceptable. What is even more annoying is that this has been a problem with yast inst_source module for a while. I cant remember if it ever had a progress indicator. I've seen this requested many times on IRC and the mailing lists but im not sure if anyone has made a feature request in bugzilla. FYI, I use rug for my software management, i add YUM sources because the progress indicator for rug works if you add YUM sources. Of course there are a couple of caveats, YUM sources added with rug do not synch with YaST. ZYPP sources do synch with yast but the rug progress indicator is broken for them. Great huh? :P Cheers Graham

Graham Anderson wrote:

What is even more annoying is that this has been a problem with yast inst_source module for a while. I cant remember if it ever had a progress indicator. I've seen this requested many times on IRC and the mailing lists but im not sure if anyone has made a feature request in bugzilla.

it's even worst when some source gives a warning windows that needs to be acknowledged before the work continue...

FYI, I use rug for my software management

Yast is the standard system and should stay so. I don't mind what subsystem is used if through yast jdd (AFAIK, Mandrake have (had?) the same sort of problem) -- http://www.dodin.net http://dodin.org/galerie_photo_web/expo/index.html http://lucien.dodin.net http://fr.susewiki.org/index.php?title=Gérer_ses_photos

I'm just putting our current packages to ftp.suse.com and mirrors for testing: ftp://ftp.suse.com/pub/people/aj/10.1-packagemanagement-update-test/ If the test is successfull, those packages will go out next week as online update. I'll write release notes later on what has changed, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

Andras Mantia wrote:

On Tuesday 23 May 2006 18:30, Andreas Jaeger wrote:

...

I'm just putting our current packages to ftp.suse.com and mirrors for testing:

ftp://ftp.suse.com/pub/people/aj/10.1-packagemanagement-update-test/

If the test is successfull, those packages will go out next week as online update. I'll write release notes later on what has changed,

I wanted to try this, but the first try is not successfull. When I tried to add the above as install-source, first I refused to import your key. It failed to add. Next I choose import, now the dialog is there after several tens of minutes (I had my lunch meantime). I guess I have to update the rpms by hand.

Andras

# rug sa ftp://ftp.suse.com/pub/people/aj/10.1-packagemanagement-update-test/ ERROR: Could not add 'ftp://ftp.suse.com/pub/people/aj/10.1-packagemanagement-update-test/': No suitable service types could be found I added that with YaST and it worked. The stuff appeared as updates (the Globe went orange) in updater. Updates were then installed. At this stage I'm so mixed up with all these adding and removin that I'm not sure what those updates did or didn't. Vahis -- http://waxborg.servepics.com http://waxborg.servepics.com/mobile/articles/vmware.html http://waxborg.servepics.com/English/Linux/susemultimedia.en.html http://waxborg.servepics.com/English/Bikes/Trackdays/index.html

Vahis writes:

# rug sa

Add: --type=yum or: --type=zypp both should work.

ftp://ftp.suse.com/pub/people/aj/10.1-packagemanagement-update-test/ ERROR: Could not add 'ftp://ftp.suse.com/pub/people/aj/10.1-packagemanagement-update-test/': No suitable service types could be found

I added that with YaST and it worked.

The stuff appeared as updates (the Globe went orange) in updater.

Updates were then installed.

At this stage I'm so mixed up with all these adding and removin that I'm not sure what those updates did or didn't.

;-) Restart zmd and zen-updater and you're current again, Andreas -- Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj/ SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126

On Wed, May 24, 2006 at 06:21:29PM +0300, Vahis wrote:

Andreas Jaeger wrote:

...

Vahis writes:

...

# rug sa

Add: --type=yum or: --type=zypp

both should work.

...

ftp://ftp.suse.com/pub/people/aj/10.1-packagemanagement-update-test/ ERROR: Could not add 'ftp://ftp.suse.com/pub/people/aj/10.1-packagemanagement-update-test/': No suitable service types could be found

I added that with YaST and it worked.

The stuff appeared as updates (the Globe went orange) in updater.

Updates were then installed.

At this stage I'm so mixed up with all these adding and removin that I'm not sure what those updates did or didn't.

;-)

Restart zmd and zen-updater and you're current again,

Andreas

# rug sa --type=yum ftp://ftp.suse.com/pub/people/aj/10.1-packagemanagement-update-test/ ERROR: Please provide a name for the service

# rug sa --type=zypp ftp://ftp.suse.com/pub/people/aj/10.1-packagemanagement-update-test/ ERROR: Please provide a name for the service

man rug is unclear to me here. Is written for people who can read or what? :)

What shoul I name it and how? Don't they have names, everybody naming them themselves as they like might cause problems in remembering what they are later?

Use rug sa --type=zypp ftp://ftp.suse.com/pub/people/aj/10.1-packagemanagement-update-test/ update-test You missed the actual name at the end of the commandline. Then: rug sub update-test Ciao, Marcus

Vahis wrote:

I wonder if I should now run them, this is my attempted-to-keep installation. I ran those already on my factory one but I don't know yet what they did.

I ran them. After that the globe went orange again with: Update Version: 1424-0 Installed Version: Category: Recommended Status: Applied bugfix for dhcp (DHCLIENT_HOSTNAME_OPTION) It saya Applied but because of the orange I attempted to run it with result: 21|/content (ftp://ftp.gwdg.de/pub/linux/misc/suser-guru/rpm/10.1/) 23|389A563CC272A126|Andreas Jaeger |93A3365ECE47B889DF7FFED1389A563CC272A126 23|A84EDAE89C800ACA|SuSE Package Signing Key |79C179B2E1C820C1890F9994A84EDAE89C800ACA 21|/repodata/repomd.xml (http://packman.iu-bremen.de/suse/10.1) And the globe stays orange Vahis -- http://waxborg.servepics.com http://waxborg.servepics.com/mobile/articles/vmware.html http://waxborg.servepics.com/English/Linux/susemultimedia.en.html http://waxborg.servepics.com/English/Bikes/Trackdays/index.html

Martin Schlander wrote:

onsdag 24 maj 2006 17:22 skrev Marcus Meissner:

...

Use

rug sa --type=zypp ftp://ftp.suse.com/pub/people/aj/10.1-packagemanagement-update-test/ update-test

I've replaced Yum with Zypp in the examples on this page. http://en.opensuse.org/Examples_using_rug

It seems that using zypp is generally the best approach.

Martin / cb400f

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org

That page is cool! My understanding improved significantly. It's not hard to improve from zero :) Is this update-test going to stay there for testing or is it a one-off? Should it be kept? Vahis -- http://waxborg.servepics.com http://waxborg.servepics.com/mobile/articles/vmware.html http://waxborg.servepics.com/English/Linux/susemultimedia.en.html http://waxborg.servepics.com/English/Bikes/Trackdays/index.html

Marcus Meissner wrote:

...

That page is cool!

My understanding improved significantly. It's not hard to improve from zero :)

Is this update-test going to stay there for testing or is it a one-off? Should it be kept?

We will reissue this set of packages in there as regular online update once testing has finished.

Of course we can now do more such one-offs ;)

Ciao, marcus

--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org

OK. I'll keep it on my "factory machine" I ran the stuff seemingly successfully and removed it from my desktop machine. Testing now with adding and removing sources and software with rug and Updater/Installer. Looking good so far... Vahis -- http://waxborg.servepics.com http://waxborg.servepics.com/mobile/articles/vmware.html http://waxborg.servepics.com/English/Linux/susemultimedia.en.html http://waxborg.servepics.com/English/Bikes/Trackdays/index.html

On Wed, May 24, 2006 at 08:11:58PM +0200, Marcus Meissner wrote:

Of course we can now do more such one-offs ;)

I believe that such a directory should be part of the Factory process all the time. If not for actual updates, then at least for testing purposes. It should be a nice way to test online updates. Just to test the update process. Edit the Release Notes to include: Update worked or just change an icon. Just something to test the process. -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

On Wed, May 24, 2006 at 09:17:41PM +0200, Marcus Meissner wrote:

...

It should be a nice way to test online updates. Just to test the update process. Edit the Release Notes to include: Update worked or just change an icon. Just something to test the process.

I have been planning this for regular online updates, but we did not (and likely still don't) have resources to do so.

I am not talking about doing actual online updates. I am talking about a directory to *test* online updates in Factory, Alpha, Beta and RC. e.g. just one file that will be updated and that is the "Release notes" or somthing else competely irrelevant to the working of the system itself. Perhaps just a test added to the realease notes that states that no real security updates are done. That way we have a directory to point to for our online updates during the pre-release period and see what goes right or wrong. So no real (security) updates, but a rocess to *test* the process. At this moment, I think there is no way we can test YOU or similar processes with zen. Such a directory would make it possible to test these processes. -- houghi http://houghi.org http://www.plainfaqs.org/linux/ http://www.netmeister.org/news/learn2quote.html

Today I went outside. My pupils have never been tinier...

On Tuesday 23 May 2006 08:05, Marcus Meissner wrote:

We cannot confirm this behaviour.

parse-metadata occassionaly leads to a slow down, but only a minute at most and not on bootup.

Is it possible that parse-metadata or update-status are looping waiting for the next metadata file to download? Please read the following and consider this as a contributing factor somewhere in the update stack chain. If not related to the problems with parse-metadata or update-status in it's own right it highlights symptoms many users are reporting. A user last night on #suse was having difficulty adding a mirror for the main installation source. His symptoms were that the inst_source module would seem to 'freeze' after he clicked the finish button. Now knowing that the main repo can take a while to download, and knowing that there is no progress indicator ( <hint> a *working* progress indicator for inst_source would be an improvement by orders of magnitude I cannot convey in written text </hint> ) I suspected that it was maybe a slow download of the repo metadata after he had clicked finish. I asked the user to try a few things and I was surprised to discover he would have the same problem for smaller repos with small sized metadata, I asked him to try adding a ZYPP source using rug and the same response, he would say that 'rug had stalled, it had frozen on 0% progress'. This was indicative of reports from many users in #suse over the past couple of weeks. Many of them report the same symptoms. Now, knowing the mirror is good and knowing that in rug the progress indicator when adding a ZYPP source is broken ( <hint> a *working* progress indicator for rug when adding ZYPP sources would be an improvement by orders of magnitude I cannot convey in written text </hint> ) I asked the user to add the same repository as a YUM source, knowing the progress indicator for YUM actually works ( <hint> Oh wait, this one works ;) </hint> ) I was quite suprised to discover just how slow his download of the catalog meta data was adding a YUM source. [09:14] * spyderous watches '13.0 bytes/s' [09:19] <cenuij> spyderous: your mirror is on your campus yeah? [09:21] <spyderous> cenuij: yeah, i get 1+M/s downloads [09:21] <cenuij> and your attached to the campus network with a 100Mbit/sec connection? [09:24] <spyderous> cenuij: sorry, yeah i am. didn't see what you said [09:27] <cenuij> spyderous: ok one more thing if you dont mind please :) could you try a wget on inst-source/suse/repodata/filelists.xml.gz ? [09:28] <spyderous> 42% [===============> ] 7,363,246 1.31M/s ETA 00:08 So, on a 100Mbit/sec LAN/WAN connection the update stack was transfering the repo metadata at a staggering 13.0 bytes/s and from the same repo he was able to transfer metadata at 1.31M/s I understand this is not scientific, or conclusive and other factors may be at work here but we were able to reproduce the same symptoms and slow transfer using the update stack. Eventually he was able to add the main installation repo, I asked him how long it took; "20-30 minutes". I asked the user to file a bug report, hopefull he will. Of course if anyone has time to test this or profile whatever network aware part of the update stack may be causing this... Cheers the noo Graham

jdd wrote:

Frank-Michael Fischer wrote:

...

Might sound a bit emotional, but the "parse-metadata" problem turns 10.1 into a virtually unusable desktop for my customers (and me) really. In certain server setups it might be acceptable that the system needs up to 30 minutes after reboot before giving full power to the users. But on a desktop?

I never had this problem.

I even see that the time to refresh when I lauch yast software install is significantly faster on 10.1 than on 10.0

jdd

Whenever someone (like me) runs into this bug on three different machines with a 10.1 default installation it does not really help to know whether there are chances no to run into it. ;-) FMF