Am Montag 25 Mai 2009 schrieb Martin Schlander:

What I did notice was that on a cold start of for example Firefox or Systemsettings in openSUSE there's 3-5 secs of intense disk activity, while in Mandriva they'd just pop right up without any (audible) disk activity - on the same hardware with 1 gig of ram. Hmm, your openSUSE is installed from scratch too? Because updated suses are always slower than installed. That's unfortunate, but even for ext4 there doesn't exist a reliable defrag tool yet ;(

And what would be interesting to know if this happens also in a virtual machine. If so, it would be way easier to debug and to find the reason. If it's specific to hardware, it's a puzzle. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Am Montag 25 Mai 2009 schrieb Martin Schlander:

Mandag den 25. maj 2009 10:20:19 skrev Stephan Kulow:

...

Am Montag 25 Mai 2009 schrieb Martin Schlander:

...

What I did notice was that on a cold start of for example Firefox or Systemsettings in openSUSE there's 3-5 secs of intense disk activity, while in Mandriva they'd just pop right up without any (audible) disk activity - on the same hardware with 1 gig of ram.

Hmm, your openSUSE is installed from scratch too? Because updated suses are always slower than installed. That's unfortunate, but even for ext4 there doesn't exist a reliable defrag tool yet ;(

I always do fresh install. However I don't format /home, just do some "manual" cleanup. But this particular laptop I had only owned for about 4 months at that time, and I don't use it very much and there's tons of free space on it. So I don't think it could have been too fragmented.

And the application startup difference is really huge, the first time I started Firefox on Mandriva I was litterally in disbelief thinking "what the f...?!?" .. usually starting Firefox means it's time to go get some coffee.

Possibly they simply preload Firefox? That's what we did in the past. I'll have a look, I should be able to starting firefox :) Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Am Montag 25 Mai 2009 schrieb Wolfgang Rosenauer:

Stephan Kulow schrieb:

...

Am Montag 25 Mai 2009 schrieb Martin Schlander:

...

Mandag den 25. maj 2009 10:20:19 skrev Stephan Kulow: And the application startup difference is really huge, the first time I started Firefox on Mandriva I was litterally in disbelief thinking "what the f...?!?" .. usually starting Firefox means it's time to go get some coffee.

Possibly they simply preload Firefox? That's what we did in the past. I'll have a look, I should be able to starting firefox :)

11.1 still uses preloading for Firefox (in theory). Only on kde3.

But looking at /etc/preload.d/Firefox that's partly useless because it's only created for the GA version which was 3.0b5 and therefore references all the stuff below /usr/lib64/xulrunner-1.9b5 where it's long gone.

How could that be solved? Shipping/creating a preload config within Firefox itself and therefore keep it up to date? Any other solutions?

Yeah, the same way as I solved the booting preload: by listening to the system while it boots. The same I'll have to do for the desktop I guess. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Am Montag 25 Mai 2009 schrieb Robert Kaiser:

Martin Schlander wrote:

...

And the application startup difference is really huge, the first time I started Firefox on Mandriva I was litterally in disbelief thinking "what the f...?!?" .. usually starting Firefox means it's time to go get some coffee.

Knowing how much stuff Mozilla applications (like Firefox) load at startup, I wonder as much as coolo if they preload it if it's _that_ snappy.

If I accounted correctly, it loads 90MB during startup under a KDE desktop. That took over a minute on first start here. If you preload these into your cache (emulating a previous firefox start), it just takes a couple of seconds. Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Mon, May 25, 2009 at 6:09 PM, Martin Schlander wrote:

Please note that my comparisons were between openSUSE 11.1 and Mandriva 2009.0. I don't touch that brown stuff.

I'm pretty sure the versions are about the same, if anything openSUSE 11.1 is a bit newer (1-2 months) than Mandriva 2009.0.

And it was not only Firefox, though that was the most notable difference. But also KDE applications like systemsettings, dolphin started significantly faster. Especially on cold starts the difference is quite noticable.

I am sorry if it sounds like a lame question. You tested in the same machine with similar size of data (same /home partition ?) ? Applications like firefox will have varying performance based on data size (history, bookmarks etc.). -- Sankar P http://psankar.blogspot.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Sankar P wrote: <snip>

Firefox becomes a hog over long usage (few months). The sqlite database after getting bloated will cause serious delays in startup.

You can shutdown firefox and from the ~/.mozilla directory run:

find . -name '*.sqlite' -exec sqlite3 '{}' 'VACUUM;' \;

This will compact the disk blocks of your sqlite database and from then on, firefox will start noticeably faster if your are a long time user.

I started a project to vaccumize sqlite databases (of various applications) periodically, as they are the culprit for slowness in most of the desktop applications - f-spot, banshee, firefox, evolution etc. I stopped working on it after I got moved out of the openSUSE teams. May be it is good to re-start the project. ( http://gitorious.org/vacuumizer )

The reasoning that I gave for slowness could be wrong and the actual issue may be different. But I have fixed, "firefox starts slow" issue for lots of users with this hack and couldn't resist replying.

A big hand to you :) I couldn't resist to try that, and, wow! That was cool shit. My installation is about a year old 11.0 and that really made FF run nicely. Thank you again, Vahis -- "Sunrise 4:23am (EEST), sunset 10:14pm (EEST) at Espoo, Finland (17:50 hours daylight)" http://waxborg.servepics.com Linux 2.6.25.20-0.1-default #1 SMP 2008-12-12 20:30:38 +0100 x86_64 5:10pm up 68 days 20:06, 11 users, load average: 0.66, 0.36, 0.21

-- Sankar P http://psankar.blogspot.com

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

-----Original Message----- From: sankar.curiosity@gmail.com [mailto:sankar.curiosity@gmail.com] On Behalf Of Sankar P Sent: Tuesday, May 26, 2009 8:31 AM To: Vahis Cc: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] The plan to speed up openSUSE 11.2

On Mon, May 25, 2009 at 7:41 PM, Vahis wrote:

...

Sankar P wrote:

...

You can shutdown firefox and from the ~/.mozilla directory run:

find . -name '*.sqlite' -exec sqlite3 '{}' 'VACUUM;' \;

This will compact the disk blocks of your sqlite database and from then on, firefox will start noticeably faster if your are a long time user.

I started a project to vaccumize sqlite databases (of various applications) periodically, as they are the culprit for slowness in most of the desktop applications - f-spot, banshee, firefox, evolution etc. I stopped working on it after I got moved out of the openSUSE teams. May be it is good to re-start the project. ( http://gitorious.org/vacuumizer )

A big hand to you :)

I couldn't resist to try that, and, wow! That was cool shit. My installation is about a year old 11.0 and that really made FF run nicely.

I am glad that it helped you. I still remember the surprise in the face of my friends after I do this trick on their machine. May be it is time I resume my project and make the sqlite compaction done in the background without users having to do it explicitly.

It would be great. -- S pozdravom / Best regards, Rasto -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Pavol Rusnak wrote:

Rastislav Krupanský wrote:

...

...

I am glad that it helped you. I still remember the surprise in the face of my friends after I do this trick on their machine. May be it is time I resume my project and make the sqlite compaction done in the background without users having to do it explicitly.

It would be great.

I think that simple shell script running from cron would suffice. No need for extra C code or GUI. We just need to collect the files (by find command - eg. firefox or by knowing exact location - eg. banshee) and run sqlite vacuum command.

I created a wiki page[1] and repo on github[2]. Package will follow shortly. If you'd like to add other sqlite-enabled applications, please drop me a note.

I'm using MySQL myself with Amarok, but I guess it would be fine for the default Amarok using sqlite. Vahis -- "Sunrise 4:21am (EEST), sunset 10:16pm (EEST) at Espoo, Finland (17:55 hours daylight)" http://waxborg.servepics.com Linux 2.6.25.20-0.1-default #1 SMP 2008-12-12 20:30:38 +0100 x86_64 4:46pm up 69 days 19:42, 5 users, load average: 0.19, 0.25, 0.15 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Rajko M. wrote:

On Tuesday 26 May 2009 08:46:56 am Vahis wrote:

...

I'm using MySQL myself with Amarok, but I guess it would be fine for the default Amarok using sqlite.

What is better probably depends on how large is your music collection.

Yes. I was just saying that Amarok might be one of the programs benefiting from the cacuuming. I was like replying to: "If you'd like to add other sqlite-enabled applications, please drop me a note." Vahis. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

...

...

On 5/26/2009 at 05:06 PM, in message <4A1BD439.3000006@suse.cz>, Pavol Rusnak wrote: Rastislav Krupanský wrote: I am glad that it helped you. I still remember the surprise in the face of my friends after I do this trick on their machine. May be it is time I resume my project and make the sqlite compaction done in the background without users having to do it explicitly.

It would be great.

I think that simple shell script running from cron would suffice. No need for extra C code or GUI. We just need to collect the files (by find command - eg. firefox or by knowing exact location - eg. banshee) and run sqlite vacuum command.

I created a wiki page[1] and repo on github[2]. Package will follow shortly. If you'd like to add other sqlite-enabled applications, please drop me a note.

[1] http://en.opensuse.org/Vacuumizer [2] http://github.com/stickac/vacuumizer/tree/master

Yes. A simple cron job is sufficient for this. But I started the project because I wanted to learn some GTK# programming, makefiles, icon usage etc. ;-) Also, I wanted to show some progress bars, easy GUI to add new db locations, warn if the application is running, etc. A simple shell script is more than sufficient to solve the problem, though :-) It may be a good idea to backup the sqlite files before you VACUUM them. -- Sankar http://psankar.blogspot.com -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Vahis wrote:

...

Yes. A simple cron job is sufficient for this. I experienced that FF needs to be shut down before vacuuming. The database will be locked when FF runs. Wouldn't this be tricky in a cron job?

You could detect if firefox (or any other application) is running and skip the associated files (for this cron run). -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Stephan Kulow wrote:

Am Mittwoch 27 Mai 2009 schrieb Pavol Rusnak:

...

Vahis wrote:

...

...

Yes. A simple cron job is sufficient for this. I experienced that FF needs to be shut down before vacuuming. The database will be locked when FF runs. Wouldn't this be tricky in a cron job? You could detect if firefox (or any other application) is running and skip the associated files (for this cron run).

I guess it would be easier to do it in the /usr/bin/firefox wrapper script when firefox exited. you still want to check no other instance is running, but that should be easy _there_.

cron jobs for single users are a bit problematic.

Very good point. Actually all applications that I handle in my script have wrappers in /usr/bin and are not called directly: * Banshee * Evolution * F-Spot * Mozilla Firefox * Mozilla Thunderbird We could patch these wrappers to take care of vacuuming the DB at application exit (or at N-th exit, or storing the date of the last vacuum and check if it's older than N days). What do you think? -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Sankar P wrote:

On Wed, May 27, 2009 at 3:08 PM, Pavol Rusnak wrote:

...

We could patch these wrappers to take care of vacuuming the DB at application exit (or at N-th exit, or storing the date of the last vacuum and check if it's older than N days). What do you think?

Is it okay for multiple rpms to patch a single file ? (I know it is okay for something like /etc/pam.d/gdm) I am not sure if there are any packaging guidelines against such practices.

i.e., our vacuumizer will patch /usr/bin/firefox which is owned by someother package, FireFox.

No. I was suggesting to patch the individual packages, so the vacuumizer wouldn't be needed anymore. And to get these patches upstream.

If it is okay, then patching the wrappers to update on every Nth access may be the smartest fix to speedup things. In this way, you don't have to vacuumize the db-s of applications that you may never use. For instance, if someone is happy with his mutt+fetchmail, he need not worry about a new vacuumizer grinding the disk searching for 'folders.db' under ~/.evolution.

Agree. -- Best Regards / S pozdravom, Pavol RUSNAK SUSE LINUX, s.r.o Package Maintainer Lihovarska 1060/12 PGP 0xA6917144 19000 Praha 9, CR prusnak[at]suse.cz http://www.suse.cz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Stephan Kulow wrote:

I guess it would be easier to do it in the /usr/bin/firefox wrapper script when firefox exited. you still want to check no other instance is running, but that should be easy _there_.

Actually, I'm pretty sure the right thing would be to do this right in the original Firefox code, using the idle timer functionality in Mozilla that can do stuff when the browser is idle. I know this has been discussed in the "places" team (the feature that uses sqlite to store history and bookmarks) but it just might have been buried under a lot of other work over time. Would be interesting to see if bugzilla.mozilla.org has a report about this and get something going there again. If someone puts work into this, we should try to have all users of the feature (i.e. at least all Firefox and SeaMonkey users) benefit and not only the openSUSE users (as much as we like to be better than the rest of the world). Robert Kaiser -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 26.05.2009 16:13, Richard (MQ) wrote:

Vahis wrote:

...

Sankar P wrote:

<snip>

...

Firefox becomes a hog over long usage (few months). The sqlite database after getting bloated will cause serious delays in startup.

You can shutdown firefox and from the ~/.mozilla directory run:

find . -name '*.sqlite' -exec sqlite3 '{}' 'VACUUM;' \;

For me, on my Firefox 3.x.x (don't remember - .0.10?) it doesn't really help. Firefox starts slowly, shuts down even slower and frequently freezes (refreshing of RSS is way too agressive in < 3.5), hangs and sometimes crashes. I hope TraceMonkey and other stuff will make Firefox faster. Next thing I hoping to get faster is kernel config, Lennart Poettering still complains about our config, which - as he said - causes awfully huge latencies in PulseAudio... Gosh, I should forget about PulseAudio, I don't know where have I got my patience from... Crackling, skipping etc. Even on Creative Sound Blaster... -- Best regards, Jakub 'Livio' Rusinek http://jakubrusinek.pl/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Martin Schlander wrote:

Mandag den 25. maj 2009 10:20:19 skrev Stephan Kulow:

...

Am Montag 25 Mai 2009 schrieb Martin Schlander:

...

What I did notice was that on a cold start of for example Firefox or Systemsettings in openSUSE there's 3-5 secs of intense disk activity, while in Mandriva they'd just pop right up without any (audible) disk activity - on the same hardware with 1 gig of ram. Hmm, your openSUSE is installed from scratch too? Because updated suses are always slower than installed. That's unfortunate, but even for ext4 there doesn't exist a reliable defrag tool yet ;(

I always do fresh install. However I don't format /home, just do some "manual" cleanup. But this particular laptop I had only owned for about 4 months at that time, and I don't use it very much and there's tons of free space on it. So I don't think it could have been too fragmented.

And the application startup difference is really huge, the first time I started Firefox on Mandriva I was litterally in disbelief thinking "what the f...?!?" .. usually starting Firefox means it's time to go get some coffee.

Even on kubuntu, Fedora, etc. running as VM's under VirtualBox, firefox starts up in a fraction of the time it takes under native openSUSE. Something of long standing is at the root of these performance hits and it should be possible to have 2 similar boxes with openSUSE on one and another distro on the other, that way it should be possible to find the bottlenecks. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Stephan Kulow wrote:

Am Montag 25 Mai 2009 schrieb Martin Schlander:

...

What I did notice was that on a cold start of for example Firefox or Systemsettings in openSUSE there's 3-5 secs of intense disk activity, while in Mandriva they'd just pop right up without any (audible) disk activity - on the same hardware with 1 gig of ram. Hmm, your openSUSE is installed from scratch too? Because updated suses are always slower than installed. That's unfortunate, but even for ext4 there doesn't exist a reliable defrag tool yet ;(

It doesn't matter whether it's a new install or the result of a progressive update. I have 6 boxes currently running, 4 are updated boxes and 2 are new 11.1 installs upgraded to 11.2 M1 and at no stage have I noticed a change. Whatever happens is consistent, down to the same errors on an upgrade. For a humdinger see bug #487060 which came on in 11.2 Alpha0 a few days before Milestone1 - a number of applications get stuck when run as root locally, but run across the network as root with ssh -X and it's the same on all my x86_64 boxes and the one x86 box I'm running.

And what would be interesting to know if this happens also in a virtual machine. If so, it would be way easier to debug and to find the reason. If it's specific to hardware, it's a puzzle.

Greetings, Stephan

Under VirtualBox, Fedora, Kubuntu, etc. are quite swift in every way, but then I run loads more services and applications in the base openSUSE system. Last time I tried kvm, starting VM's was super slow, even slower than kubuntu on a P-II/333 laptop with 96M memory + swap and 2M video card. Using openSUSE on that laptop is fine providing a lightweight WM is used instead of KDE, kubuntu no problem. I don't hang much importance on boot up times as they are insignificant to the time taken to download some files or to build an application, so if it takes 3 minutes to get my system up, it's no big deal. It may be for shops running thousands of users and applications a business depends on, even then mainframe shops find it can take up to 2 hours from the speedy login prompt to winding everything back in from a total shutdown, that's why near 100% uptime is critically important for them. Slowness compared to RedHat, etc. has long been a complaint I have seen in several reviews going back to SuSE. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Monday May 25 2009, Cristian Morales Vega wrote:

2009/5/25 Martin Schlander :

...

So I wouldn't be so quick to dismiss these reports. And also I wouldn't focus only on boot speed, but also analyse application startup speed.

Well, application startup speed... makes me think about link time. Was https://bugzilla.novell.com/362947 ever tested?

I was going to suggest, yesterday, that library dependencies might be an issue. In the old days, the Firefox (or Mozilla, as the case may be) binaries were shipped by Mozilla (the organization) in statically linked form for maximum universality. So I decided to compare library dependencies between the current generic (x86 Linux) distribution of Firefox and the openSUSE 11.1 (latest update) version. I was very surprised to see a much _longer_ list of dependencies in the the Mozilla.com version than in the 11.1 distribution. To wit: # openSUSE 11.1 Firefox 3.0.10: % ldd /usr/lib/firefox/firefox linux-gate.so.1 => (0xffffe000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7f31000) libdl.so.2 => /lib/libdl.so.2 (0xb7f2c000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7e38000) libm.so.6 => /lib/libm.so.6 (0xb7e0f000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7dff000) libc.so.6 => /lib/libc.so.6 (0xb7ca3000) /lib/ld-linux.so.2 (0xb7f6a000) % readelf -d /usr/lib/firefox/firefox Dynamic section at offset 0x9ee4 contains 28 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libpthread.so.0] 0x00000001 (NEEDED) Shared library: [libdl.so.2] 0x00000001 (NEEDED) Shared library: [libstdc++.so.6] 0x00000001 (NEEDED) Shared library: [libm.so.6] 0x00000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x0000000f (RPATH) Library rpath: [/usr/lib/mozilla-xulrunner190-1.9.0.10] 0x0000001d (RUNPATH) Library runpath: [/usr/lib/mozilla-xulrunner190-1.9.0.10] 0x0000000c (INIT) 0x8048aa4 0x0000000d (FINI) 0x804dc8c 0x00000004 (HASH) 0x80481c4 0x6ffffef5 (GNU_HASH) 0x8048314 0x00000005 (STRTAB) 0x8048604 0x00000006 (SYMTAB) 0x8048334 0x0000000a (STRSZ) 571 (bytes) 0x0000000b (SYMENT) 16 (bytes) 0x00000015 (DEBUG) 0x0 0x00000003 (PLTGOT) 0x8052ff4 0x00000002 (PLTRELSZ) 328 (bytes) 0x00000014 (PLTREL) REL 0x00000017 (JMPREL) 0x804895c 0x00000011 (REL) 0x804894c 0x00000012 (RELSZ) 16 (bytes) 0x00000013 (RELENT) 8 (bytes) 0x6ffffffe (VERNEED) 0x804889c 0x6fffffff (VERNEEDNUM) 3 0x6ffffff0 (VERSYM) 0x8048840 0x00000000 (NULL) 0x0 -==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==- # Mozilla.com x86 Linux Mozilla: % tar jxf firefox-3.0.10.tar.bz2 % ldd firefox/firefox-bin linux-gate.so.1 => (0xffffe000) libpthread.so.0 => /lib/libpthread.so.0 (0xb7ede000) libjemalloc.so => not found libxul.so => not found libmozjs.so => not found libxpcom.so => not found libplds4.so => /usr/lib/libplds4.so (0xb7ed8000) libplc4.so => /usr/lib/libplc4.so (0xb7ed2000) libnspr4.so => /usr/lib/libnspr4.so (0xb7e95000) libdl.so.2 => /lib/libdl.so.2 (0xb7e90000) libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0xb7a99000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0xb7a7b000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0xb79e3000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0xb79c7000) libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0xb79bb000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0xb7972000) libcairo.so.2 => /usr/lib/libcairo.so.2 (0xb78ee000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0xb78e9000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0xb78a6000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb77e1000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb76ad000) libm.so.6 => /lib/libm.so.6 (0xb7684000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7590000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7581000) libc.so.6 => /lib/libc.so.6 (0xb7425000) /lib/ld-linux.so.2 (0xb7f17000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0xb7421000) libXi.so.6 => /usr/lib/libXi.so.6 (0xb7416000) libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0xb740e000) libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xb7403000) libXcomposite.so.1 => /usr/lib/libXcomposite.so.1 (0xb73ff000) libXext.so.6 => /usr/lib/libXext.so.6 (0xb73ee000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0xb73ea000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xb73e3000) libpixman-1.so.0 => /usr/lib/libpixman-1.so.0 (0xb739b000) libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7371000) libxcb-render-util.so.0 => /usr/lib/libxcb-render-util.so.0 (0xb736c000) libxcb-render.so.0 => /usr/lib/libxcb-render.so.0 (0xb7363000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0xb7358000) libxcb-xlib.so.0 => /usr/lib/libxcb-xlib.so.0 (0xb7355000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb7337000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb7333000) libgio-2.0.so.0 => /usr/lib/libgio-2.0.so.0 (0xb72be000) libpangoft2-1.0.so.0 => /usr/lib/libpangoft2-1.0.so.0 (0xb7292000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7212000) libz.so.1 => /lib/libz.so.1 (0xb71fd000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb71cc000) libglitz.so.1 => /usr/lib/libglitz.so.1 (0xb71a2000) libpcre.so.0 => /usr/lib/libpcre.so.0 (0xb716e000) libselinux.so.1 => /lib/libselinux.so.1 (0xb7151000) libexpat.so.1 => /lib/libexpat.so.1 (0xb7129000) % readelf -d firefox-bin Dynamic section at offset 0x14cc contains 43 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libpthread.so.0] 0x00000001 (NEEDED) Shared library: [libjemalloc.so] 0x00000001 (NEEDED) Shared library: [libxul.so] 0x00000001 (NEEDED) Shared library: [libmozjs.so] 0x00000001 (NEEDED) Shared library: [libxpcom.so] 0x00000001 (NEEDED) Shared library: [libplds4.so] 0x00000001 (NEEDED) Shared library: [libplc4.so] 0x00000001 (NEEDED) Shared library: [libnspr4.so] 0x00000001 (NEEDED) Shared library: [libdl.so.2] 0x00000001 (NEEDED) Shared library: [libgtk-x11-2.0.so.0] 0x00000001 (NEEDED) Shared library: [libatk-1.0.so.0] 0x00000001 (NEEDED) Shared library: [libgdk-x11-2.0.so.0] 0x00000001 (NEEDED) Shared library: [libgdk_pixbuf-2.0.so.0] 0x00000001 (NEEDED) Shared library: [libpangocairo-1.0.so.0] 0x00000001 (NEEDED) Shared library: [libpango-1.0.so.0] 0x00000001 (NEEDED) Shared library: [libcairo.so.2] 0x00000001 (NEEDED) Shared library: [libgmodule-2.0.so.0] 0x00000001 (NEEDED) Shared library: [libgobject-2.0.so.0] 0x00000001 (NEEDED) Shared library: [libglib-2.0.so.0] 0x00000001 (NEEDED) Shared library: [libX11.so.6] 0x00000001 (NEEDED) Shared library: [libm.so.6] 0x00000001 (NEEDED) Shared library: [libstdc++.so.6] 0x00000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x00000001 (NEEDED) Shared library: [libc.so.6] 0x0000000c (INIT) 0x80487b8 0x0000000d (FINI) 0x8049368 0x00000004 (HASH) 0x8048148 0x00000005 (STRTAB) 0x80483c4 0x00000006 (SYMTAB) 0x8048204 0x0000000a (STRSZ) 755 (bytes) 0x0000000b (SYMENT) 16 (bytes) 0x00000015 (DEBUG) 0x0 0x00000003 (PLTGOT) 0x804a654 0x00000002 (PLTRELSZ) 152 (bytes) 0x00000014 (PLTREL) REL 0x00000017 (JMPREL) 0x8048720 0x00000011 (REL) 0x8048710 0x00000012 (RELSZ) 16 (bytes) 0x00000013 (RELENT) 8 (bytes) 0x6ffffffe (VERNEED) 0x80486f0 0x6fffffff (VERNEEDNUM) 1 0x6ffffff0 (VERSYM) 0x80486b8 0x00000000 (NULL) 0x0 Randall Schulz -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Mandag den 25. maj 2009 21:32:25 skrev Wolfgang Rosenauer:

There was also a mail from coolo about Firefox taking about one minute to start on a cold system. Please note that I never ever saw such a behaviour. From my feeling Firefox 3.5b4 on openSUSE 11.1 starts on a cold system within 5 seconds and a hot system within one second. I have to admit that my current system is quite powerful.

So I'm wondering about which startup times people are talking here. I'm pretty sure there could be systems where it takes a long time but overall it shouln't be that slow.

I hadn't done any remotely serious research or benchmarking on this, I only brought my experience up, because someone else started the topic. For me on Mandriva a cold start of Firefox would take maybe 3-4 seconds, and on openSUSE maybe 7-9 seconds. Maybe it doesn't sound like much, but it feels like a huge difference. This is on a Fujitsu Siemens Lifebook e8110, core duo, 1 gig of ram. Three years old or so (I bought it second hand in the late summer 2008), not too fast, but not too slow either. Admittedly the Mandriva installation would be a bit fresher. But since Firefox is my secondary browser, only used where konq fails, it doesn't have a large amount of extensions or data or other funny stuff. And besides I don't think the issue is specific for Firefox either. Like I said before I found the same thing with KDE apps. Systemsettings or Dolphin would prolly start in about 1 second on Mandriva, and on openSUSE starting in 2-3 seconds after some hectic disk activity. Again, not a big difference, but if you use some application several times everyday, and suddenly it starts twice as fast, you take notice. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

It would be great if some of you volunteered to setup the following:

- a set of benchmarks that matter in real life, examples are booting into kdm prompt, booting into GNOME session, firefox start, OOo start, shutdown, .... - run these tests with different distributions on the same hardware (virtualized machines are interesting but show very often different results than real hardware that caches differently) - keep an eye on Factory and its status compared to these benchmarks.

I'm still in progress of setting up a kvm setup that installs factory daily and runs some performance checks, but I want to do this automatically and this has quite some limits. So it would be very good to have volunteers.

I compared sled gnome menu and control center start up time. On my old HP NX 6110, (1,4 CPU Celeron, 768MB RAM, VGA Intel Graphics Media Accelerator 900), the difference is significant. gnome menu Ubuntu - starts up immediately openSUSE - lasts about 1 sec. control center Ubuntu - takes cca. 1 sec. openSUSE - takes cca. 3 seconds Booting into Gnome session and shutdown i didn´t want to compare, because it wouldn´t be a fair. The newest Ubuntu 9.04 has much, much faster boot time than older openSUSE 11.1 and an older Ubuntu 8.10 i didn´t install. We should wait on 11.2 and Karmic Koala - 9.10, if we would like to compare boot time. -- S pozdravom / Best regards, Rasto -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Greg KH wrote:

On Sun, May 24, 2009 at 10:25:49PM +0200, Rastislav Krupanský wrote:

...

Hi folks.

I installed Ubuntu 9.04 and i'm unpleasantly surprised, how faster is than openSUSE 11.1.

That's because it is a newer release, not really fair to compare apples to oranges here.

...

In according to minuses from Brainstorming, http://en.opensuse.org/BrainStorming_Prague#Slow.2Funstable_applications http://en.opensuse.org/BrainStorming_Prague#Low-level_system_performance and especially article http://lizards.opensuse.org/2008/12/16/comments-on-phoronix-benchmarking-ope... by Andreas Jaeger, i want to ask, whether is any plan to speed up openSUSE 11.2?

Yes.

...

Do you realize that you should really do something with prerformance?

Yes.

Try the recently announced opensuse moblin release for an example of us booting opensuse in a few seconds. The kernel is done in less than a second, and the rest of init in another one, and x in another second. Right now the speed problems are in metacity and the rest of the x applications that we start up in the moblin default screen.

That work will all end up in 11.2.

hope this helps,

greg k-h

I have never been able to put a finger on it, perhaps Ubuntu starts fewer services. Going back a ways to kubuntu 6.04 on an old Fujitsu-Siemens laptop with 96M and a 2M video card, SuSE was unusable unless I used one of the lesser window managers, fvwm, windowmaker, etc. When I installed kubuntu it was quite responsive - the difference was obviously SuSE's KDE. Fast forward to today kubuntu 9.04 running in VirtualBox is the fastest I have come across, not only in terms of booting up, but also in bringing up applications. I have not done any checks of what services it starts. It's certainly snappier than any other VM's including previous versions of kubuntu. I wonder what the secret sauce in Moblin happens to be. A cue for another VM to try perhaps. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi, to Rajko M.:

Did you try 11.2 ?

11.2 hasn´t been released yet, just Milestone1 to Greg KH:

...

I installed Ubuntu 9.04 and i'm unpleasantly surprised, how faster is than openSUSE 11.1.

That's because it is a newer release, not really fair to compare apples to oranges here.

But guys from Phoronix compared older Ubuntu 8.10 ;-)

That work will all end up in 11.2

It´s glad to read it :-) to Martin Schlander:

So I wouldn't be so quick to dismiss these reports. And also I wouldn't focus only on boot speed, but also analyse application startup speed.

+1

PS: I should probably get around to testing if the barrier setting that we use on ext3, is the reason applications take twice as long to start as on other distros ;-)

I disabled barriers for ext3, but no affect. to Cristian Rodríguez:

What are your concrete suggestions to improve the situation ?

for example what Martin wrote. Startup speed, boot speed...all system reactions. And the most strange is, that gnome menu, developed by Novell, is slower in openSUSE than Ubuntu´s. If you haven´t tried Ubuntu, or Mandriva, you should try. You´ll see. Anyway, you can read experiences by Martin or Sid too, in this thread. -- S pozdravom / Best regards, Rasto -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Am Montag 25 Mai 2009 schrieb Stephan Kulow:

Am Sonntag 24 Mai 2009 schrieb Rastislav Krupanský:

...

Hi folks.

I installed Ubuntu 9.04 and i'm unpleasantly surprised, how faster is than openSUSE 11.1.

It would be great if some of you volunteered to setup the following:

No volunteers? It doesn't require any coding experience. Am I asking the wrong list? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On Wednesday 27 May 2009, Rastislav Krupanský wrote:

As i wrote, i just quick compared sled gnome menu and control center start up time. On my old HP NX 6110, (1,4 CPU Celeron, 768MB RAM, VGA Intel Graphics Media Accelerator 900), the difference is significant.

gnome menu Ubuntu - starts up immediately openSUSE - lasts about 1 sec.

1 second is significant? I'm sorry, but you really need to get a life. If you can't wait that long something is seriously wrong.

control center Ubuntu - takes cca. 1 sec. openSUSE - takes cca. 3 seconds

Oh gee, now it's 2 seconds..

Booting into Gnome session and shutdown i didn´t want to compare, because it wouldn´t be a fair. The newest Ubuntu 9.04 has much, much faster boot time than older openSUSE 11.1 and an older Ubuntu 8.10 i didn´t install. We should wait on 11.2 and Karmic Koala - 9.10, if we would like to compare boot time.

If i want to compare another (firefox start, OOo start ...) stuff, i´d have to reinstall(but it isn´t my intention), becuase i´m using only Ubuntu nowadays. These stuff could compare someone else.

That's good. If you don't want to do the re-install, then there really isn't much to talk about is there? You are the one complaining about a couple of seconds and then just decide YOU aren't going to mess with it anymore. If it isn't re-installed, then you can't do a real comparison. If there is no real comparison, then all your assumptions are simply irrelavant. You were the one that originally started the thread that I've been watching, and now you don't even run the OS. Strange that you are still here complaining. Mike -- Powered by SuSE 11.0 Kernel 2.6.25 KDE 3.5 Kmail 1.9 12:23pm up 2 days 19:40, 3 users, load average: 2.05, 2.13, 2.18 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

On 2009/05/27 13:44 (GMT+0200) Martin Schlander composed:

But every app in both KDE and GNOME (cold) starting very noticably faster, in seemingly just about any other distro on the same hardware, is something that should be taken seriously.

*The* most common complaint about openSUSE from non-fanboys and distro- tourists is that "openSUSE is slow". While people usually don't specify what exactly is slow when and where, there seems to be some truth to it when it comes to application (cold) startup.

People usually assume it's caused by the starting of a few additional services compared to other distros, but I don't buy that a few extra services can make such a big difference on a modern "Vista capable" computer. I think something is wrong on a lower level - whether it is linking, file system, kernel, compile options or something else I have no clue - but I'm quite sure something is wrong somewhere.

Like I said before, the feeling of responsiveness with regards to application startup in Mandriva 2009.0 compared to openSUSE (9.2 -> 11.1), was simply shocking.

I've run *SUSE, Fedora, Mandriva & Kubuntu (plus doz; KDE only) for years, but only *SUSE & OS/2 run 24/7 (11.0 on my file & web server, OS/2 for web use & general chores). The rest are basically for testing alphas, betas, RCs, and making comparisons among the various distros. The two 24/7 machines are always the newest hardware, meaning all the others are somewhere between modestly and massively slower hardware. Startup time is just not something I pay much attention to. It nearly always seems slower on Linux than doz, so I'm used to "slow" startup. The only "speed" issue I have/had with openSUSE that I can recall is https://bugzilla.novell.com/show_bug.cgi?id=447142 All that said, SuSEfirewall* & *beagle* here are always either not installed, or disabled in all runlevels. -- "A fool gives full vent to his anger, but a wise man keeps himself under control." Proverbs 29:11 NIV Team OS/2 ** Reg. Linux User #211409 Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

-----Original Message----- From: Mike [mailto:mike@mikenjane.net] Sent: Wednesday, May 27, 2009 12:31 PM To: opensuse-factory@opensuse.org Subject: Re: [opensuse-factory] The plan to speed up openSUSE 11.2

On Wednesday 27 May 2009, Rastislav Krupanský wrote:

...

As i wrote, i just quick compared sled gnome menu and control center start up time. On my old HP NX 6110, (1,4 CPU Celeron, 768MB RAM, VGA Intel Graphics Media Accelerator 900), the difference is significant.

...

gnome menu Ubuntu - starts up immediately openSUSE - lasts about 1 sec.

1 second is significant? I'm sorry, but you really need to get a life. If you can't wait that long something is seriously wrong.

...

control center Ubuntu - takes cca. 1 sec. openSUSE - takes cca. 3 seconds

Oh gee, now it's 2 seconds..

...

Booting into Gnome session and shutdown i didn´t want to compare, because it wouldn´t be a fair. The newest Ubuntu 9.04 has much, much faster boot time than older openSUSE 11.1 and an older Ubuntu 8.10 i didn´t install. We should wait on 11.2 and Karmic Koala - 9.10, if we would like to compare boot time.

If i want to compare another (firefox start, OOo start ...) stuff, i´d have to reinstall(but it isn´t my intention), becuase i´m using only Ubuntu nowadays. These stuff could compare someone else.

That's good. If you don't want to do the re-install, then there really isn't much to talk about is there? You are the one complaining about a couple of seconds and then just decide YOU aren't going to mess with it anymore. If it isn't re-installed, then you can't do a real comparison. If there is no real comparison, then all your assumptions are simply irrelavant.

You were the one that originally started the thread that I've been watching, and now you don't even run the OS. Strange that you are still here complaining.

Mike, please, don´t write that i´m the only one complaining, because it´s not a true. I´m not complaining. I wrote my experiences and i just wanted to ask, if is any plan to speed up openSUSE. Just ask. That´s all. If nobody wants to do something with performance, i don´t care. -- S pozdravom / Best regards, Rasto -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Hi guys. I've compared first(cold) start and repeated start of applications. Those are not any special benchmarks, but might be enough for getting the idea. Ubuntu 9.04 with Gnome 2.26.1 and openSUSE 11.2, Milestone2 with Gnome, both with ext4 file system, in Vmware on the same machine. Ubuntu 9.04 Start from Grub to gdm - 39 seconds Shutdown from gdm - 11 seconds Evolution first - 4s repeated - 2s Pidgin first - 4s repeated - 2s OpenOffice writer first - 11s repeated - 3s Brasero - 2s repeated - 1s Firefox first - 5s repeated - 2s Control center first - 3s repeated - 2s Gimp first - 11s repeated - 9s Nautilus first - 2s repeated - 1s openSUSE 11.2 Milestone2 Start from Grub to gdm - 61 s Shutdown from gdm - 15s Evolution first - 6s repeated - 4s Pidgin first - 5,8s repeated - 2,5s OpenOffice writer first - 19,3s repeated - 9s Brasero first - 3,5s repeated - 2,4s Firefox first - 9,5s repeated - 4s Control center first - 5s repeated - 3s Gimp first - 23s repeated - 17s Nautilus first - 5,5s repeated - 2,5s Hope this helps -- S pozdravom / Best regards, Rasto -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2009/5/29 jdd :

Rastislav Krupanský a écrit :

...

Hi guys.

I've compared first(cold) start and repeated start of applications. Those are not any special benchmarks, but might be enough for getting the idea. Ubuntu 9.04 with Gnome 2.26.1 and openSUSE 11.2, Milestone2 with Gnome, both with ext4 file system, in Vmware on the same machine.

may be a "ps ax" from the first login to see what services ar run

jdd

Here you are Ubuntu http://pastebin.com/faf3b155 openSUSE http://pastebin.com/f182365a7 -- S pozdravom / Best regards, Rasto -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

...

...

On 6/2/2009 at 14:00, Stephan Kulow wrote: Am Freitag 29 Mai 2009 schrieb Rastislav Krupanský: Gimp first - 11s repeated - 9s

...

Gimp first - 23s repeated - 17s

I tried it on my system (using time, and trying to close as fast as possible, when the image is painted) dle3ams@3120-2914:~> time gimp real 0m17.052s user 0m6.044s sys 0m2.812s dle3ams@3120-2914:~> time gimp real 0m7.656s user 0m4.480s sys 0m0.620s Most of the time I can see it scanning and loading extensions. Might be worthy to compare if other distros have the same amount of extensions here, in order to be sure we compare the same. Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

...

...

On 6/2/2009 at 14:41, Stephan Kulow wrote: Honestly I don't care. If I open gimp, I'm more interested in the 8 seconds difference than having extensions in 8 more scripting languages.

Yes, but that's exactly the point. Our install has a bunch of scripts that are all loaded, which seems to cost quite some time. That's why it would be (imho) interesting to see if the other compared distro had the same set of plugins / scripts to load. If yes, well, then we're back to mark 0. If it has less, we have an easy way to optimize our speed here for example. (like splitting scripts out in a separate package, marked with a Suggests: for exampled.) Dominique -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

2009/6/2 Stephan Kulow :

Am Dienstag 02 Juni 2009 schrieb Stephan Kulow:

...

Am Freitag 29 Mai 2009 schrieb Rastislav Krupanský:

...

Gimp first - 11s repeated - 9s

Gimp first - 23s repeated - 17s

I'll check if I can reproduce this here.

I can't with kvm. Here it takes around 8s to start gimp repeatedly with the same kvm config - both installed gnome live cds (they call it ubuntu though :).

I get ~21000 relocations on openSUSE and ~17000 on ubuntu, which is an indicator that they have less libraries and/or modules. But once they are in cache, the shouldn't make a difference. And especially not as large as you measured it. How much memory did you give your installs btw?

I expected that you will probably have a faster start, ;-) because i tried it on an older desktop machine (Athlon XP 2500), in Vmware and i gave to my virtual machine 768MB memory. It doesn´t matter to me. But i only wanted to point that start is faster in another distro. And not only for Gimp, but for all applications, boot time and shutdown. :-( -- S pozdravom / Best regards, Rasto -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org

Dne pondělí 25 Květen 2009 13:15:23 Stephan Kulow napsal(a):

Am Sonntag 24 Mai 2009 schrieb Rastislav Krupanský:

...

Hi folks.

I installed Ubuntu 9.04 and i'm unpleasantly surprised, how faster is than openSUSE 11.1.

It would be great if some of you volunteered to setup the following:

- a set of benchmarks that matter in real life, examples are booting into kdm prompt, booting into GNOME session, firefox start, OOo start, shutdown, .... - run these tests with different distributions on the same hardware (virtualized machines are interesting but show very often different results than real hardware that caches differently) - keep an eye on Factory and its status compared to these benchmarks.

Do you have any details about that? What needs to be done and how? I can use my HP laptop as a testing machine.

Greetings, Stephan

Best regards Michal Vyskocil -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org