I have a HP Pavilion 9205CA with a Turion processor and 1.25 Gig of memory. There is also a 100Gig SATA drive. Gary B Kevin Dupuy wrote:

On Sun, 2007-12-16 at 16:41 -0500, Gary Baribault wrote:

...

Hi all,

Anyone else seeing Beagle really kill performance? I have disabled it and my machine finally is perky, but every now and then, I find it in memory again. How do I arange it to chew up less memory and CPU or kill it once and for all?

Gary B

Some people have a lot of trouble with Beagle, I don't. If you want to kill it off for good, you can uninstall it. What are your computer's specs, I'm trying to figure out why some are having issues and others aren't.

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

Kevin Dupuy wrote:

...

...

Some people have a lot of trouble with Beagle, I don't. If you want to kill it off for good, you can uninstall it. What are your computer's specs, I'm trying to figure out why some are having issues and others aren't.

I don't seem to have a problem with it.

Oh. I'm thinking it is maybe the size of a user's /home.

My condo is about 900 sq feet. ;-) -- Use OpenOffice.org <http://www.openoffice.org> -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sunday 16 December 2007 04:19:48 pm Linda Walsh wrote:

Gary Baribault wrote:

...

Hi all,

Anyone else seeing Beagle really kill performance? I have disabled it and my machine finally is perky, but every now and then, I find it in memory again. How do I arange it to chew up less memory and CPU or kill it once and for all?

--- Might try making sure the "cfq" block algorithm is being used, then set 'beagle' to run at lowest priority (nice -19 beagle-start-script).

info:nice "Nicenesses range at least from -20 (resulting in the most favorable scheduling) through 19 (the least favorable)."

That should help it not use so much CPU, and, if cfq is working well, it should set beagle's disk priority to near lowest as well.

Of course, if beagle is using 500MB and you only have 512MB, you are likely to get "alot" of swapping.

I'd also wonder, does beagle use "alot" of resources during some initial "full-index" phase, after which it can run with less resources as it does incremental updates...?

BTW -- anyone compared it to "swish" (another full-system indexing util with web-based interface).

Linda

Beagle is actually silent helper in background. There was problem in initial release of 10.2 where it was started Beagle and mandb. Running both on same hard disk made system sluggish, and that happened on every boot, few minutes after GUI was up. Many users noticed Beagle and missed to see mandb, and since removing one of programs that were competing for hard disk access made situation much better, Beagle earned bad reputation and it is still comming back trough Google search. Beagle-helper runs now with nice=19, so it is already the lowest priority and it will not make problem even on initial indexing. The beagled runs with nice=7, so it is also below most processes in the system. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Rajko M. wrote:

On Sunday 16 December 2007 04:19:48 pm Linda Walsh wrote:

...

Gary Baribault wrote:

...

Hi all,

Anyone else seeing Beagle really kill performance? I have disabled it and my machine finally is perky, but every now and then, I find it in memory again. How do I arange it to chew up less memory and CPU or kill it once and for all?

---

Might try making sure the "cfq" block algorithm is being used, then set 'beagle' to run at lowest priority (nice -19 beagle-start-script).

info:nice "Nicenesses range at least from -20 (resulting in the most favorable scheduling) through 19 (the least favorable)." === Right -- and to set priority "19", you use "nice -19 prog", but you knew that, right? :-)

...

That should help it not use so much CPU, and, if cfq is working well, it should set beagle's disk priority to near lowest as well.

Of course, if beagle is using 500MB and you only have 512MB, you are likely to get "alot" of swapping.

I'd also wonder, does beagle use "alot" of resources during some initial "full-index" phase, after which it can run with less resources as it does incremental updates...?

BTW -- anyone compared it to "swish" (another full-system indexing util with web-based interface).

Linda

Beagle is actually silent helper in background.

--- No such thing in standard linux. The cpu nice doesn't affect the disk-io priority unless you have the non-standard "cfq" scheduling algorithm enabled. The default when I installed 10.2 recently, I believe was the 'anticipatory' deadline. Unfortunately, while it may be good for server workloads, and better for throughput, 'cfq' is better for interactive use. A background process can easily saturate the disk if it runs at full speed (even if process is 'niced' down). In addition to using 'cfq' ('fair' queuing), you can run the beagle processes in 'batch' priority -- which will be below normal user processes. Beagled -- is that a background indexer and beagle-helper is to aid foreground searches? Or...why are there two processes?

There was problem in initial release of 10.2 where it was started Beagle and mandb. Running both on same hard disk made system sluggish, and that happened on every boot, few minutes after GUI was up.

Mandb finishes after a few minutes - virtually never runs -- can't see how it would drag down beagle... Course if it was a real beagle, just wave some treats in front of it -- it'll get active & feisty! :-)

Many users noticed Beagle and missed to see mandb, and since removing one of programs that were competing for hard disk access made situation much better, Beagle earned bad reputation and it is still comming back trough Google search.

Beagle-helper runs now with nice=19, so it is already the lowest priority and it will not make problem even on initial indexing. The beagled runs with nice=7, so it is also below most processes in the system.

--- If people think it is a problem, why not run it at 19? But a disk-bound nice-19 process can still hog the system. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Dave Howorth wrote:

Linda Walsh wrote:

...

No such thing in standard linux. The cpu nice doesn't affect the disk-io priority unless you have the non-standard "cfq" scheduling algorithm enabled. The default when I installed 10.2 recently, I believe was the 'anticipatory' deadline. Unfortunately, while it may be good for server workloads, and better for throughput, 'cfq' is better for interactive use. A background process can easily saturate the disk if it runs at full speed (even if process is 'niced' down).

I'm curious and didn't find an answer with a quick google. How does one inspect what algorithm is in use and/or change it? Is it a runtime option or build-time?

It has to be built in when the kernel is built, but I think both 10.2 and 10.3 have the alternate I/O schedulers compiled in as modules. The default can be set at compile time. So far, I only know of a way to change schedulers at boot time. Booting the kernel with the "elevator=" argument allows specifying an I/O scheduler. Valid values (if they are all compiled in) are: elevator=as elevator=cfq elevator=deadline elevator=noop They choose/enable the "Anticipatory", "completely fair queuing", "deadline", or "noop" schedulers, respectively. I believe the default used to be "anticipatory", but this isn't ideal for desktop use, but tries to optimize total throughput (good for servers processing large non-interactive programs). The "ionice" command in util-linux allows modifying cfq priorities. Recommended google search terms (from book "Linux Kernel Primer") would be "Modular IO Schedulers" and "Jens Axboe". In my quick search just now, didn't see anything about run-time selection, but didn't go far down the page. The boot time option might be the only way to go right now... Sorry couldn't be more help.... linda -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wednesday 19 December 2007 04:54:01 am Linda Walsh wrote:

Rajko M. wrote: ...

...

...

--- Might try making sure the "cfq" block algorithm is being used, then set 'beagle' to run at lowest priority (nice -19 beagle-start-script).

info:nice "Nicenesses range at least from -20 (resulting in the most favorable scheduling) through 19 (the least favorable)."

=== Right -- and to set priority "19", you use "nice -19 prog", but you knew that, right? :-)

I knew what info tells: nice -n <niceness> program In practice it accepts also nice -19 program and nice --19 program for negative values. It is just the way you quoted command line that confused me. It appeared to me as text. ....

...

Beagle is actually silent helper in background.

--- No such thing in standard linux. The cpu nice doesn't affect the disk-io priority unless you have the non-standard "cfq" scheduling algorithm enabled. The default when I installed 10.2 recently, I believe was the 'anticipatory' deadline. Unfortunately, while it may be good for server workloads, and better for throughput, 'cfq' is better for interactive use. A background process can easily saturate the disk if it runs at full speed (even if process is 'niced' down).

In addition to using 'cfq' ('fair' queuing), you can run the beagle processes in 'batch' priority -- which will be below normal user processes.

Beagled -- is that a background indexer and beagle-helper is to aid foreground searches? Or...why are there two processes?

You question is the answer :-) http://beagle-project.org/Main_Page I can't see Joe Shaw, jumping in discussion. He knows the best about the beagle.

...

There was problem in initial release of 10.2 where it was started Beagle and mandb. Running both on same hard disk made system sluggish, and that happened on every boot, few minutes after GUI was up.

--- Mandb finishes after a few minutes - virtually never runs -- can't see how it would drag down beagle...

It was 2 processes competing about single hard disk and few minutes computer was in very bad shape, and it was computer that had no problems with quite a few applications running at the same time. I experienced the problem and initially I was against Beagle, but Joe helped to find real reason for problems and ever since I can't see it as a resource hog. I'm just happy user.

Course if it was a real beagle, just wave some treats in front of it -- it'll get active & feisty! :-)

Sure :-)

...

Many users noticed Beagle and missed to see mandb, and since removing one of programs that were competing for hard disk access made situation much better, Beagle earned bad reputation and it is still comming back trough Google search.

Beagle-helper runs now with nice=19, so it is already the lowest priority and it will not make problem even on initial indexing. The beagled runs with nice=7, so it is also below most processes in the system.

--- If people think it is a problem, why not run it at 19? But a disk-bound nice-19 process can still hog the system.

Yes, but this is not the case with Beagle here. The problem was solved in 10.2, and should not appear in 10.3, unless Mono jumped in as regression factor. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Joe Sloan wrote:

Gary Baribault wrote:

...

Hi all,

Anyone else seeing Beagle really kill performance? I have disabled it and my machine finally is perky, but every now and then, I find it in memory again. How do I arange it to chew up less memory and CPU or kill it once and for all?

The standard procedure for me on any new suse build is to nuke beagle completely (along with fixing the broken non-root paths, and installing the chronically missing rwhod)

That means, specifically, doing an "rpm -qa | grep beagle", nuking every resulting item and also any dependencies such as kerry or kio_beagle.

Joe

rpm -e $(rpm -qa | grep beagle) works nicely -- David C. Rankin, J.D., P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Joe Sloan wrote:

David C. Rankin wrote:

...

rpm -e $(rpm -qa | grep beagle)

works nicely

It looks good, but it won't remove beagle because kerry needs it.

But in general I agree with your elegant approach.

Joe

Ahah, You are correct! Looks like it will have to be: rpm -e $(rpm -qa | grep beagle) kerry -- David C. Rankin, J.D., P.E. Rankin Law Firm, PLLC 510 Ochiltree Street Nacogdoches, Texas 75961 Telephone: (936) 715-9333 Facsimile: (936) 715-9339 www.rankinlawfirm.com -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sunday 16 December 2007 05:56:05 pm Joe Sloan wrote:

David C. Rankin wrote:

...

rpm -e $(rpm -qa | grep beagle)

works nicely

It looks good, but it won't remove beagle because kerry needs it.

But in general I agree with your elegant approach.

Joe

You can safely remove kerry and anything beagle. and make some noise about it, perhaps it can attract the attention of developers that develop bloated software. In my mind it is really sad that anything not related to gaming or heavy duty engineering simulations abuses hardware thousands of times harder than it could or should... it used to be that open source software was a lean and mean fighting machine, now the typical linucs install is about 2-3x that of an xp partition, don't know anything about vista. and running the proggies often brings up situations like beagle or a software update, much better than 10.2 but still awful timewise, on dual core or even quad core cpus with oodles of ram!!!!! d. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Well, it's not quite that easy... Beagle libraries are used by a bunch of installed programs, but I un-installed all of the rest and have my nice snappy thunderbird back .. :-) Thanks for all of the suggestions, made for fun reading Gary B Joe Sloan wrote:

kanenas@hawaii.rr.com wrote:

...

On Sunday 16 December 2007 05:56:05 pm Joe Sloan wrote:

...

David C. Rankin wrote:

...

rpm -e $(rpm -qa | grep beagle)

works nicely

It looks good, but it won't remove beagle because kerry needs it.

But in general I agree with your elegant approach.

Joe

You can safely remove kerry and anything beagle.

Right, and I always remove kerry - I was just pointing out a flaw in the one-liner provided earlier as an example.

...

and make some noise about it, perhaps it can attract the attention of developers that develop bloated software.

In my mind it is really sad that anything not related to gaming or heavy duty engineering simulations abuses hardware thousands of times harder than it could or should... it used to be that open source software was a lean and mean fighting machine, now the typical linucs install is about 2-3x that of an xp partition, don't know anything about vista. and running the proggies often brings up situations like beagle or a software update, much better than 10.2 but still awful timewise, on dual core or even quad core cpus with oodles of ram!!!!!

Well it still can be very lean and mean, but if you install suse, you have to do some work to get it that way.

Joe

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

And just for your general information, with Beagle installed, SuSE was using 1.5Gig of Memory and 256Meg of Swap. After removing Beagle and a reboot, I have 887Meg free and no swap used, I would think that Beagle qualifies as a HOG. I don't care what it offers as an advantage, it isn't worth that, (I have about 2 Gigs of EMail it was indexing) Gary B Joe Sloan wrote:

kanenas@hawaii.rr.com wrote:

...

On Sunday 16 December 2007 05:56:05 pm Joe Sloan wrote:

...

David C. Rankin wrote:

...

rpm -e $(rpm -qa | grep beagle)

works nicely

It looks good, but it won't remove beagle because kerry needs it.

But in general I agree with your elegant approach.

Joe

You can safely remove kerry and anything beagle.

Right, and I always remove kerry - I was just pointing out a flaw in the one-liner provided earlier as an example.

...

and make some noise about it, perhaps it can attract the attention of developers that develop bloated software.

In my mind it is really sad that anything not related to gaming or heavy duty engineering simulations abuses hardware thousands of times harder than it could or should... it used to be that open source software was a lean and mean fighting machine, now the typical linucs install is about 2-3x that of an xp partition, don't know anything about vista. and running the proggies often brings up situations like beagle or a software update, much better than 10.2 but still awful timewise, on dual core or even quad core cpus with oodles of ram!!!!!

Well it still can be very lean and mean, but if you install suse, you have to do some work to get it that way.

Joe

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

Gary Baribault wrote:

And just for your general information, with Beagle installed, SuSE was using 1.5Gig of Memory and 256Meg of Swap.

After removing Beagle and a reboot, I have 887Meg free and no swap used, I would think that Beagle qualifies as a HOG. I don't care what it offers as an advantage, it isn't worth that, (I have about 2 Gigs of EMail it was indexing)

Well, I've never rebooted after nuking beagle, but I've always noticed similar benefits - Unfortunately beagle got my attention because whilst playing quake 3 arena online I would experience annoying pauses during game play, lasting up to half a second. Naturally I would often be fragged during these comatose periods. Removing beagle and zmd brings back silky smooth performance. It would be great if the beagle devs could take a page from the boinc playbook, and only use CPU when it is not being used by other apps. Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Mon, 2007-12-17 at 06:44 -0600, M Harris wrote:

On Monday 17 December 2007 12:22, Sloan wrote:

...

It would be great if the beagle devs could take a page from the boinc playbook, and only use CPU when it is not being used by other apps. You mean like the windoze devs...?

cpu timeslice should *never* be in the hands of app developers. The kernel schedules the cpu, and timeslice.... not app devs. (windoze never mind)

However, a sysadmin can adjust the cpu timeslice for beagle, or any other cpu intensive app, so that they crawl along happily in the background. The apps under such control take longer to complete of course... but in the case of massive indexing like beagle --who cares?

Beagle already does nice itself and employ strategies for reducing work when the CPU is not idle. However I/O is a problem and non-root processes can't change their own I/O priority iirc. -JP -- JP Rosevear <jpr@novell.com> Novell, Inc. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Mon, 2007-12-17 at 20:32 +0100, Anders Johansson wrote:

On Monday 17 December 2007 19:58:18 JP Rosevear wrote:

...

Beagle already does nice itself and employ strategies for reducing work when the CPU is not idle. However I/O is a problem and non-root processes can't change their own I/O priority iirc.

Actually, they can. "All" they need is CAP_SYS_ADMIN

A bit silly to not allow a process to downgrade its own priority, with nice I can set myself to absolute rock bottom. Even sillier is it to have the capability baked in with some real admin capabilities. It should be more fine grained

I concur. And in fact the system wide index thats shared for documentation, apps, etc does run as a privileged user and takes advantage of ionice (/etc/cron.daily/beagle-crawl-system).

But what beagle could do is start as root (or CAP_SYS_ADMIN), run ioprio_set(), then immediately drop root perms.

Have you met our security team? :-) All kidding aside, this sounds like an interesting idea, although indexing happens in a shorter lived indexing processes rather than a proper daemon so the indexer would have to do that itself. -JP -- JP Rosevear <jpr@novell.com> Novell, Inc. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wednesday 19 December 2007 23:51:42 Aaron Kulkis wrote:

Anders Johansson wrote:

...

On Monday 17 December 2007 19:58:18 JP Rosevear wrote:

...

Beagle already does nice itself and employ strategies for reducing work when the CPU is not idle. However I/O is a problem and non-root processes can't change their own I/O priority iirc.

Actually, they can. "All" they need is CAP_SYS_ADMIN

A bit silly to not allow a process to downgrade its own priority, with nice I

All processes can downgrade their own priority.

Not I/O priority, no.

Nice with positive (lower priority) values is available to all processes. Only negative (higher priority) values need the root user ID.

Yes, that's what I said. Anders -- Madness takes its toll -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

M Harris wrote:

On Monday 17 December 2007 12:22, Sloan wrote:

...

It would be great if the beagle devs could take a page from the boinc playbook, and only use CPU when it is not being used by other apps.

You mean like the windoze devs...?

Nope, I mean the boinc devs - windoze is not a worthy role model.

cpu timeslice should *never* be in the hands of app developers.

Who said anything about cpu timeslice? we're talking pure userland here.

The kernel schedules the cpu, and timeslice.... not app devs. (windoze never mind)

It's defintely in the hands of the app, in the sense that the app can *not* demand resources.

However, a sysadmin can adjust the cpu timeslice for beagle, or any other cpu intensive app, so that they crawl along happily in the background. The apps under such control take longer to complete of course... but in the case of massive indexing like beagle --who cares?

The problem is, Aunt Martha should not have to wrestle with that. There should be a sane default setting. Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Monday 17 December 2007 13:24, Anders Johansson wrote:

I think you're confusing "nice" with applications' getting priority when they're in the foreground (which is the windows strategy), but that's the other way around Yes... I was alluding to the windoze strategy, but not confused about nice... must poking fun at the windoze strategy...

Fortunately there is a way of doing it - with ionice you can set IO scheduling priority idle, and since it's the IO that kills you, it should be good enough Yes... nice | ionice are our friends...

-- Kind regards, M Harris <>< -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-12-17 at 20:24 +0100, Anders Johansson wrote:

Fortunately there is a way of doing it - with ionice you can set IO scheduling priority idle, and since it's the IO that kills you, it should be good enough

Only if you are root. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHaaV4tTMYHG2NR9URAjquAJ0WUVdIlNyQPtFm7gQeeRIh9xGZbwCeM+q9 yUJtrXFoCB4PUd0pwIEF2FY= =5cre -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2007-12-19 at 15:23 -0800, Randall R Schulz wrote:

...

Only if you are root.

Is ionice different from (CPU) nice? I.e., is it not possible for any user to lower the priority (increase the absolute nice value) while only root can improve the priority (decrease the nice value)?

Unfortunately, that's right. You need to be root to increase and even decrease I/O priority using program ionice. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHabFXtTMYHG2NR9URAo5oAJ0T4/+aNG8gSO13iW53NO8S4YhynQCaA1aZ zHLZnRR/3zoq7mDNQMBaMjw= =p6Bh -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2007-12-19 at 16:29 -0800, Randall R Schulz wrote:

...

Unfortunately, that's right. You need to be root to increase and even decrease I/O priority using program ionice.

How odd. Thankfully, I'm Lord and Master of my machines!

So am I, but I don't want to run apps as root. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHabqQtTMYHG2NR9URAjWrAJ4tPSHtT3tKnamvjEcyKrhmC+hZFgCfR4SZ gyKowUHU65TdJde4NE2TvDI= =A3Y7 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Wednesday 2007-12-19 at 17:35 -0800, Randall R Schulz wrote:

...

So am I, but I don't want to run apps as root.

Actually, that's not necessary. You can always become root for the purpose of exercising privileged operations and then go back to being a "regular" user to carry out everyday tasks.

E.g.:

su root -c 'ionice -c 3 su nonRootUser -c "ultimate command"'

Or, if you're already root:

ionice -c 3 su nonRootUser -c "ultimate command"

Ah! Ah! Didn't know that trick. I have to try that! [...] Doesn't work... nimrodel:~ # ionice -c 1 su - cer -c "xine --verbose" Who needs friends when you can sit alone in your room and drink? This is xine (X11 gui) - a free video player v0.99.5. (c) 2000-2007 The xine Team. Built with xine library 1.1.8 (1.1.8) Found xine library version: 1.1.8 (1.1.8). Cannot open display nimrodel:~ # Mayby doesn't like "su -". Another try: nimrodel:~ # ionice -c 1 su cer -c "xine --verbose" Yes! Lets check on another terminal: nimrodel:~ # ps au | grep xine root 14954 0.0 0.1 3124 1208 pts/27 S+ 03:29 0:00 su cer -c xine --verbose cer 14955 2.8 2.7 205492 28944 pts/27 Sl+ 03:29 0:02 xine --verbose root 15122 0.0 0.0 2040 652 pts/20 S+ 03:30 0:00 grep xine nimrodel:~ # ionice -p 14955 realtime: prio 4 Good! It is runnin with realtime priority as user. I like that! Now I'll have to write this to a sudo rule, some how. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHadVptTMYHG2NR9URApzDAJ48R0AxaO2cevw1mSP53Tk8IvX9bwCdGJVx lUumOPNTtan8hgdyvsuQYKE= =6ce8 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Sloan wrote:

Gary Baribault wrote:

...

And just for your general information, with Beagle installed, SuSE was using 1.5Gig of Memory and 256Meg of Swap.

After removing Beagle and a reboot, I have 887Meg free and no swap used, I would think that Beagle qualifies as a HOG. I don't care what it offers as an advantage, it isn't worth that, (I have about 2 Gigs of EMail it was indexing)

Well, I've never rebooted after nuking beagle, but I've always noticed similar benefits -

Unfortunately beagle got my attention because whilst playing quake 3 arena online I would experience annoying pauses during game play, lasting up to half a second. Naturally I would often be fragged during these comatose periods. Removing beagle and zmd brings back silky smooth performance. It would be great if the beagle devs could take a page from the boinc playbook, and only use CPU when it is not being used by other apps.

That's done by the scheduler in the kernel, not the app. And it's not just CPU usage... beagle stresses the entire system (especially clogging up filesystem I/O with a flood of outstanding requests which keep the disk-heads moving all the time, and introducing a big delay in disk I/O responsiveness for any other process (both already running and new processes).

Joe

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

Joe Sloan wrote:

Aaron Kulkis wrote:

...

Sloan wrote:

...

Gary Baribault wrote:

...

And just for your general information, with Beagle installed, SuSE was using 1.5Gig of Memory and 256Meg of Swap.

After removing Beagle and a reboot, I have 887Meg free and no swap used, I would think that Beagle qualifies as a HOG. I don't care what it offers as an advantage, it isn't worth that, (I have about 2 Gigs of EMail it was indexing)

Well, I've never rebooted after nuking beagle, but I've always noticed similar benefits -

Unfortunately beagle got my attention because whilst playing quake 3 arena online I would experience annoying pauses during game play, lasting up to half a second. Naturally I would often be fragged during these comatose periods. Removing beagle and zmd brings back silky smooth performance. It would be great if the beagle devs could take a page from the boinc playbook, and only use CPU when it is not being used by other apps. That's done by the scheduler in the kernel, not the app. And it's not just CPU usage... beagle stresses the entire system (especially clogging up filesystem I/O with a flood of outstanding requests which keep the disk-heads moving all the time, and introducing a big delay in disk I/O responsiveness for any other process (both already running and new processes).

If you look at boinc, it's possible to do this with clever programming, completely in userland. When we've run boinc, the load average on the box rises to the point that you'd think the box is in trouble, judging from load average indications, but then you notice that everything is still quite responsive.

"clever programming" is something I was a big fan of when I was in high school and college in the 1980's. Then I got out into the real world, where "clever code" usually translates very quickly into "unmaintainable code." I used to LOVE programming in assembly language. And it would be very good if the world was static and unchanging. HOWEVER...the real world is constantly changing, and code written in assembly langauge has a very VERY short lifespan -- making it suitable only for embedded systems...and only then on short production runs for items which you WILL NOT be producing the product 2 years later. (or if you're doing something with really REALLY unusual constraints, like trying to fit a program and it's data into the on-board memory of a Motorola 68HC11 so that you have full use of ALL of the I/O ports as such, without having to use any as address/data busses.

I haven't looked at the boinc code, but it's not new (I ran such tests in 2002 or so), and it's cross platform code, nothing linux specific there and all userspace, no kernel code.

Joe

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

On Sunday 13 January 2008 11:07, Randall R Schulz wrote:

....

So a program like the Beagle indexer has to be smart enough about the load it offers to get its work done as quickly as possible without interfering with interactive use.

By the way, I'm not saying I think Beagle does (or doesn't) need to do more or better along these lines. I don't have enough experience or information to have such an opinion.

...

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

Gary Baribault wrote:

And just for your general information, with Beagle installed, SuSE was using 1.5Gig of Memory and 256Meg of Swap.

After removing Beagle and a reboot, I have 887Meg free and no swap used, I would think that Beagle qualifies as a HOG. I don't care what it offers as an advantage, it isn't worth that, (I have about 2 Gigs of EMail it was indexing)

But but but....is that *all the time*?... Or is it doing some "initial" indexing? I thought someone else said that it took "a while" (long time) to index their whole disk, but after it was done, it only needed to smaller, incremental overnight runs. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

HI Kanenas et al, On Monday 17 December 2007 06:10, kanenas@hawaii.rr.com wrote:

it used to be that open source software was a lean and mean fighting machine, now the typical linucs install is about 2-3x that of an xp partition, don't know anything about vista. and running the proggies often brings up situations like beagle or a software update, much better than 10.2 but still awful timewise, on dual core or even quad core cpus with oodles of ram!!!!! d.

This is really apples and oranges here. I have XP on a single XP, when I loaded it all there was only the very min desktop, nothing else. On the other hand SuSE 10.1 is on a DVD and I have 100's of programs that Windows does not even offer. JIM -- Jim Hatridge Linux User #88484 Ebay ID: WartHogBulletin ------------------------------------------------------ WartHog Bulletin Info about new German Stamps http://www.WartHogBulletin.de Many Enemies -- Much Honor! Anti-US Propaganda stamp collection http://www.manyenemies-muchhonor.info An American in Bavaria http://www.gaubodengalerie.de -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Sun, 2007-12-16 at 21:46 -0600, Peter Van Lone wrote:

On Dec 16, 2007 4:39 PM, Joe Sloan <joe@tmsusa.com> wrote:

...

The standard procedure for me on any new suse build is to nuke beagle completely

Beagle doesn't give me any problems at all ... and I use it often to "find stuff" ... I guess if I was using the box as a server I would remove it, but otherwise it seems to me that removing it automatically is more a statement concerning how little you value desktop search, more than a statement about Beagle itself?

...

(along with fixing the broken non-root paths, and installing

What do you consider "the broken non-root paths"? Just curious.

Peter

I agree with you. I have no issue with Beagle, I think maybe the issues are related to the size of the Home folder...? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Peter Van Lone wrote:

On Dec 16, 2007 4:39 PM, Joe Sloan <joe@tmsusa.com> wrote:

...

The standard procedure for me on any new suse build is to nuke beagle completely

Beagle doesn't give me any problems at all ... and I use it often to "find stuff" ... I guess if I was using the box as a server I would remove it, but otherwise it seems to me that removing it automatically is more a statement concerning how little you value desktop search, more than a statement about Beagle itself?

...

(along with fixing the broken non-root paths, and installing

What do you consider "the broken non-root paths"? Just curious.

I have to fix the path to deal with the complaints of users who complain that e.g. "ifconfig" isn't installed, or who maybe have to type a full path for common commands. There's IMHO no reason a normal desktop user shouldn't be able to run many commands which reside in /sbin or /usr/sbin. Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Aaron Kulkis wrote:

Joe Sloan wrote:

...

I have to fix the path to deal with the complaints of users who complain that e.g. "ifconfig" isn't installed, or who maybe have to type a full path for common commands. There's IMHO no reason a normal desktop user shouldn't be able to run many commands which reside in /sbin or /usr/sbin.

Unix has always been like that, too.

It used to be that many admin commands that are now in /sbin or /usr/sbin used to be in /etc. And /etc was never in any user's path except for root's.

I had to edit the paths even more extensively in hpux, solaris or aix - in fact anything in /opt or /usr/local usually wasn't even in root's path - but I expect to spend time fixing things up to make those OSes work correctly. Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Dave Howorth wrote:

Joe Sloan wrote:

...

in fact anything in /opt or /usr/local usually wasn't even in root's path

I should hope not! root should have a strictly limited path to limit security exploits.

I'm not sure the lack of finish characteristic of the old school unices provides the security benefits you perceive. In any event the question becomes, is it lack of polish, or a carefully calculated attempt to limit the damage done by a bad superuser? The fact that not just roots path, but everybodys path seems a bit anemic on the old school unices, strongly hints at the former. IMHO the general user's path should certainly include commonly used utilities located in non-world-writable directories. Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Joe Sloan wrote:

Aaron Kulkis wrote:

...

Joe Sloan wrote:

...

...

I have to fix the path to deal with the complaints of users who complain that e.g. "ifconfig" isn't installed, or who maybe have to type a full path for common commands. There's IMHO no reason a normal desktop user shouldn't be able to run many commands which reside in /sbin or /usr/sbin.

Unix has always been like that, too.

It used to be that many admin commands that are now in /sbin or /usr/sbin used to be in /etc. And /etc was never in any user's path except for root's.

I had to edit the paths even more extensively in hpux, solaris or aix - in fact anything in /opt or /usr/local usually wasn't even in root's path

AND THEY'RE NOT SUPPOSED TO BE!!! That's a security risk. Root is for ADMINISTRATIVE use, not running apps.

- but I expect to spend time fixing things up to make those OSes

Hat to say it, but no, you were possibly introducing security holes into those systems. Very few apps in /opt or /usr/local are ever tested for safety under root's UID.

work correctly.

Joe

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

Joe Sloan wrote:

Aaron Kulkis wrote:

...

Joe Sloan wrote:

...

...

I had to edit the paths even more extensively in hpux, solaris or aix - in fact anything in /opt or /usr/local usually wasn't even in root's path AND THEY'RE NOT SUPPOSED TO BE!!! That's a security risk.

Root is for ADMINISTRATIVE use, not running apps.

I'm not sure what you're getting at - are you saying it's a security risk for root to run "top" on solaris or hpux? A shame really, one of my favorite apps. How about linux? It's in root's path on every linux distro I've seen.

But that is getting completely away from the point, which was that suse provides for root a fully functional path, but removes e.g. /sbin and /usr/sbin from the path of non-root users, which needs fixing up.

...

...

- but I expect to spend time fixing things up to make those OSes Hat to say it, but no, you were possibly introducing security holes into those systems. Very few apps in /opt or /usr/local are ever tested for safety under root's UID.

Examples, please? What would be the security advantage of typing "/opt/SunWzztop/bin/top" every time, instead of "top", with /opt/SunWzztop/bin in the path?

akulkis@kulkix:~> which top /usr/bin/top akulkis@kulkix:~> Why isn't top in /usr/bin where it belongs? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Sloan wrote:

Aaron Kulkis wrote:

...

Joe Sloan wrote:

...

Examples, please? What would be the security advantage of typing "/opt/SunWzztop/bin/top" every time, instead of "top", with /opt/SunWzztop/bin in the path? akulkis@kulkix:~> which top /usr/bin/top akulkis@kulkix:~>

Why isn't top in /usr/bin where it belongs?

Our solaris boxes always had top and similar utilities in /opt. Maybe it's different on solaris 10 (haven't checked), but historically, all the old school unix vendors shipped pretty bare bones systems from a usability point of view, and any useful extras tended to go either in /opt or /usr/local.

We observe a few rules of thumb for the PATH of root - "." is verboten, and world writable directories are out (actually any directory writable by someone other than root is suspect). Other than those restrictions, we prefer to use the path variable to make life less awkward and tedious.

And since top is trustworthy, just put a symbolic link in /usr/bin to the top executable. Admittedly, it's a patch up, but it's superior to playing around with the $PATH variable(*) all the time (*) for one, it doesn't help much for anyone who has a currently running login with open shell windows, unless they log off, or at the very least, shut all the shell windows, and open up new ones. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Aaron Kulkis pecked at the keyboard and wrote:

Joe Sloan wrote:

...

...

root's UID.

Examples, please? What would be the security advantage of typing "/opt/SunWzztop/bin/top" every time, instead of "top", with /opt/SunWzztop/bin in the path?

akulkis@kulkix:~> which top /usr/bin/top ^^^^^^^^

akulkis@kulkix:~>

Why isn't top in /usr/bin where it belongs?

Looks like it is to me. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

lets say /opt/SunWzztop/bin is not first on your path, and for some reason a directory in your path was writable by some malicious user - if they put a top in there, then all of a sudden when you type in top, expecting to get /opt/SunWzztop/bin/top, you get another top instead. And this top does funky stuff like rm -rf / whoops. -----Original Message----- From: Joe Sloan [mailto:joe@tmsusa.com] Sent: Thursday, 20 December 2007 5:30 p.m. To: opensuse@opensuse.org Subject: Re: [opensuse] Beagle under 10.3 is really eating up my CPU --snip--

...

- but I expect to spend time fixing things up to make those OSes

Hat to say it, but no, you were possibly introducing security holes into those systems. Very few apps in /opt or /usr/local are ever tested for safety under root's UID.

Examples, please? What would be the security advantage of typing "/opt/SunWzztop/bin/top" every time, instead of "top", with /opt/SunWzztop/bin in the path? Joe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Joe Sloan wrote:

Gary Baribault wrote:

...

Hi all,

Anyone else seeing Beagle really kill performance? I have disabled it and my machine finally is perky, but every now and then, I find it in memory again. How do I arange it to chew up less memory and CPU or kill it once and for all?

The standard procedure for me on any new suse build is to nuke beagle completely (along with fixing the broken non-root paths, and installing the chronically missing rwhod)

That means, specifically, doing an "rpm -qa | grep beagle", nuking every resulting item and also any dependencies such as kerry or kio_beagle.

yeah, those two "helper" programs are annoying as hell, too. Everyone associated with Beagle should be forced to program exclusively on Windows for the rest of their natural lives.

Joe

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

On Mon, 2007-12-17 at 09:18 -0500, JP Rosevear wrote:

On Sun, 2007-12-16 at 16:41 -0500, Gary Baribault wrote:

...

Hi all,

Anyone else seeing Beagle really kill performance? I have disabled it and my machine finally is perky, but every now and then, I find it in memory again. How do I arange it to chew up less memory and CPU or kill it once and for all?

Usually this indicates you have a problematic file (usually its broken or corrupt) that causes the index helper to go into a loop while indexing.

See http://beagle-project.org/Troubleshooting_CPU for instructions on how to report such a bug.

-JP -- JP Rosevear <jpr@novell.com> Novell, Inc.

I was looking for a page like that, thanks... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Clayton wrote:

...

...

Anyone else seeing Beagle really kill performance? I have disabled it and my machine finally is perky, but every now and then, I find it in memory again. How do I arange it to chew up less memory and CPU or kill it once and for all?

Usually this indicates you have a problematic file (usually its broken or corrupt) that causes the index helper to go into a loop while indexing.

See http://beagle-project.org/Troubleshooting_CPU for instructions on how to report such a bug.

A bit late to the discussion here... I also have to kill Beagle every time I do an install. I tried it again with the 10.3 install I did this weekend. It sucked up so much of my system resources that I could barely do anything else... this is on a *clean* default install (not an upgrade) on an AMD Athlon 64 X2 3800+ with 2Gb of RAM, a /home

with basically no data, but about 1.2TB of data on other mount points. My CPU.. both cores.. were running about 99%. RAM was full, and swap was filling up as well. The whole computer was grinding to a halt. When I finally managed top open a terminal and run top... Beagle was there consuming 100% of everything it could. I left Beagle run for a while... an afternoon... and it never changed. Kept my CPU nice and toasty warm though. In the end I sopped the daemon, and removed every trace of Beagle I could find. The result... the computer is back to normal. The 10.3 install is noticeably faster than the previous 10.2 install (also without Beagle).... and I'm happy.. .although a bit puzzled how it is that anyone finds Beagle useable.

This is typical behavior, and the developers have known about it for a long time, because there are written complaints about it all over the place. And the devs haven't done shit about it. which is why I joked about beating them with baseball bats until they do fix it. Because apparently, extreme disgust with the horrible performance characteristic of their creation doesn't seem to motivate them one bit.

As a contrast, I can install the Google Desktop indexer (on the dual core system), and I never notice it is there. It indexes roughly the same scope of data (I think). It never runs so that I am aware it's indexing. My other apps carry on with no noticeable impact on performance.

I see a few people here saying Beagle runs fine for them with no noticeable impact on performance... how? I've struggled with Beagle since it first appeared on the openSUSE scene. I have seen it's appalling impact on performance over several installs on several different hardware configurations. Not once have I seen it "work" in any measure that could be considered good.

Personally, I think they're either lying, or not paying attention.

I will continue to try it out with each new install I do, but... i don't hold out a lot of hope. I've kind of lumped it in with zmd... another app that is on my search and destroy list for a new install. Once those two apps are gone from a default install the computer works great with openSUSE.

Yep! Why these system-resource hogs which offer functionality which is .. peripheral at best... are installed by default is utterly insane. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Monday 14 January 2008 02:22:18 am Clayton wrote:

I see a few people here saying Beagle runs fine for them with no noticeable impact on performance... how?

It seems that you monitor Beagle in a first time after installation. Though there is pops up note telling that computer will be slower in a first few minutes. Later on you shouldn't notice indexing. Though that it should be optional as you suggested in another post as the version is 'beagle-0.2.18-30' which by any interparetation of version string is early development. On the other hand, how many people will ever attempt to test software with so low version (except Linux users)? -- Regards, Rajko -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Monday 14 January 2008 05:03:11 am Aaron Kulkis wrote:

Rajko M. wrote:

...

On Monday 14 January 2008 02:22:18 am Clayton wrote:

...

I see a few people here saying Beagle runs fine for them with no noticeable impact on performance... how?

It seems that you monitor Beagle in a first time after installation. Though there is pops up note telling that computer will be slower in a first few minutes. Later on you shouldn't notice indexing.

Though that it should be optional as you suggested in another post as the version is 'beagle-0.2.18-30' which by any interpretation of version string is early development. On the other hand, how many people will ever attempt to test software with so low version (except Linux users)?

Which brings back the question...

Why in the hell is Beagle part of the default installation?

it's 0.2 level, and it runs like complete crap.

The problem is that I don't see any bug report mentioned here, and right now I can't help. -- Regards, Rajko -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Mon, 2008-01-14 at 22:30 +0200, Alexey Eremenko wrote:

Yes, BTW, beagle is eating my CPU too... and I really would like to see this feature _disabled by default_ in the upcoming openSUSE 11.0.

-- -Alexey Eremenko "Technologov" As has been said before, that is something that a BUG needs to be filed. If you are not sure how to do this, if you'll provide us with somemore info, we could help you with that.

Disabling a major feature of the desktop should NOT be an option on the table. -- Kevin "Yo" Dupuy | Public Email: <kevin@kevinsword.com> Happy New Year from Yo.media! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Mon, 2008-01-14 at 06:03 -0500, Aaron Kulkis wrote:

Rajko M. wrote:

...

On Monday 14 January 2008 02:22:18 am Clayton wrote:

...

I see a few people here saying Beagle runs fine for them with no noticeable impact on performance... how?

It seems that you monitor Beagle in a first time after installation. Though there is pops up note telling that computer will be slower in a first few minutes. Later on you shouldn't notice indexing.

Though that it should be optional as you suggested in another post as the version is 'beagle-0.2.18-30' which by any interparetation of version string is early development. On the other hand, how many people will ever attempt to test software with so low version (except Linux users)?

Which brings back the question...

Why in the hell is Beagle part of the default installation?

it's 0.2 level, and it runs like complete crap.

As we know, in the open source community, version numbers can mean different things to different projects. Beagle is NOT a project meant for testing, it is a project for use in user's desktops. -- Kevin "Yo" Dupuy | Public Email: <kevin@kevinsword.com> Happy New Year from Yo.media! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2008-01-14 at 12:35 +0100, Clayton wrote:

I let Beagle run longer than 24h on the dual core system. System response remained horrible. A friend installed 10.2 and then updated everything including Beagle... it ran for a couple of weeks with Beagle killing his system performance before he called and asked what was wrong. So, I am not talking 30 seconds of annoyance here... this is days of uptime on fast machines... and weeks on slower machines.

And that is a bug you may report. There was a link with instructions.

...

...

with basically no data, but about 1.2TB of data on other mount points.

Which you could tell beagle not to index. That's a lot of data.

True, but a significant portion of it is video. Mostly very large files eating up a lot of that diskspace.... not millions of small text files that need to be indexed. Indexing 2 or 3 hundred binary video files should not take that long.

It indexes content, not just filenames, but I don't think it does anything with multimedia files. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHi1wctTMYHG2NR9URAn2RAJ0TvSAGDPJPqgCzVdoJbPFjEAFplgCdG7eJ 0RHxXbXaiIUUzZeozbwVnPo= =OXiA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Mon, 2008-01-14 at 12:35 +0100, Clayton wrote:

...

...

I see a few people here saying Beagle runs fine for them with no noticeable impact on performance... how?

It seems that you monitor Beagle in a first time after installation. Though there is pops up note telling that computer will be slower in a first few minutes. Later on you shouldn't notice indexing.

I let Beagle run longer than 24h on the dual core system. System response remained horrible. A friend installed 10.2 and then updated everything including Beagle... it ran for a couple of weeks with Beagle killing his system performance before he called and asked what was wrong. So, I am not talking 30 seconds of annoyance here... this is days of uptime on fast machines... and weeks on slower machines.

...

version is 'beagle-0.2.18-30' which by any interparetation of version string is early development. On the other hand, how many people will ever attempt to test software with so low version (except Linux users)?

Test by choice is a good thing... lots of us here install from Factory just to see what works. I have a VM I do that in all the time. Lots of things break and I have to roll back to a previous snapshot (which is why I like to use a VM instead of a native system)

Setting it as part of the default install makes the new users test it as well. That isn't giving the new user a lot of choice.

...

...

with basically no data, but about 1.2TB of data on other mount points.

Which you could tell beagle not to index. That's a lot of data.

True, but a significant portion of it is video. Mostly very large files eating up a lot of that diskspace.... not millions of small text files that need to be indexed. Indexing 2 or 3 hundred binary video files should not take that long.

C.

Since noone seems to have brought this up before... http://beagle-project.org/Troubleshooting_CPU -- Kevin "Yo" Dupuy | Public Email: <kevin@kevinsword.com> Happy New Year from Yo.media! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wed, 2007-12-19 at 13:59 -0800, Linda Walsh wrote:

These days, an interactive desktop user should almost never have more swap than physical memory -- even having swap=memory is too slow in many cases if the swap is being used frequently (> once/week).

I have 2 GB of real memory and 10 GB of swap on my interactive desktop machine but I'm probably not a normal user :) When the swap gets used, it slows the machine down, but it's usually better than having the program crash. And the machine is still usable. Much worse (i.e. unusable) is when there's heavy file access, usually NFS, which is why I'm interested in the cfq scheduling! The symptoms then are almost as bad as when our one and only DNS server has a senior moment (but it should be getting a younger sibling soon). Cheers, Dave -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Wednesday 19 December 2007 01:02:56 pm Aaron Kulkis wrote:

ah... ionice seems to be a new invention. I'll give it a try when I build a new system this month.

Even if one nices and ionices beagle, there still is the matter of swap space getting filled. Usually it is when that happens when ugly thoughts against the developers spring to life. is there a "swapnice" or something for control of max swap space an app can use? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Thursday 20 December 2007 09:38:46 am Carlos E. R. wrote:

The Thursday 2007-12-20 at 09:22 -1000, kanenas@hawaii.rr.com wrote:

...

Even if one nices and ionices beagle, there still is the matter of swap space getting filled. Usually it is when that happens when ugly thoughts against the developers spring to life. is there a "swapnice" or something for control of max swap space an app can use?

If an application need memory, there is no memory free, and there is swap, the kernel will give it as much as it wants - unless you limit it with ulimit and friends.

-- Cheers, Carlos E. R.

a quick "info ulimit" reveals that perhaps the option RLIMIT_RSS can tell beagle to not fill all ram and swap, no? if so, then a tiny little script could totally control every aspect of resourse utilization by beagle. has anyone tried that? even i could do a small script with nice, ionice and ulimit only... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2007-12-22 at 16:06 +0100, Anders Johansson wrote: [ulimit]

The real solution here is to find and fix the bug that causes beagle to allocate so much memory. It doesn't happen on all systems.

When it happens, a bug should be opened, so that the developers can investigate it. It shouldn't be hidden away by tricks like that, it should be exposed so it can be solved once and for all

Actually, it helps solve it, sometimes. The application crashes, probably with an error, maybe a core dump or a backtrace, and it can be examined. If it doesn't crash, there is nothing to report. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHbUK+tTMYHG2NR9URAglVAJ0ZmRSqUDp9M1Fx2NlfUhVud7qP9QCfciB6 w0c77ulPFsQUYWoHdJhKay8= =h6Ok -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Anders Johansson wrote:

On Saturday 22 December 2007 18:00:43 Carlos E. R. wrote:

...

The Saturday 2007-12-22 at 16:06 +0100, Anders Johansson wrote:

[ulimit]

...

The real solution here is to find and fix the bug that causes beagle to allocate so much memory. It doesn't happen on all systems.

When it happens, a bug should be opened, so that the developers can investigate it. It shouldn't be hidden away by tricks like that, it should be exposed so it can be solved once and for all Actually, it helps solve it, sometimes. The application crashes, probably

I wouldn't say "probably". It shouldn't be par for the course for an application to not check return values from memory allocation functions

As I said earlier... the whole thing is poorly written. Beagle should be scrapped and started over from the ground up, starting with the design assumption that it is to behave as an unobtrusive background process, not the current one which can take over the whole system with a "feed me" attitude as if the whole purpose for a computer and its data to even exist is to provide something for a beagle process to index.

Anders

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

On Saturday 22 December 2007 07:29:04 pm Linda Walsh wrote:

...

...

...

The Saturday 2007-12-22 at 16:06 +0100, Anders Johansson wrote:

...

The real solution here is to find and fix the bug that causes beagle to allocate so much memory. It doesn't happen on all systems.

---. Without question, this is the best solution.

...

Anders Johansson wrote:

...

I wouldn't say "probably". It shouldn't be par for the course for an application to not check return values from memory allocation functions

Aaron Kulkis wrote:

...

As I said earlier... the whole thing is poorly written.

--- And you say this based on??? Do you have _any_ expertise in the source? (if you do, sorry, but your attitude is not productive). It _appears_ you know nothing about how it is written but are basing your opinion on its behavior in certain configurations.

This is why I made a comment about *not* using "swap" on a system -- if you are using swap on any regular basis (my threshhold is using swap, *anytime*, during 'normal' day-to-day usage), you are running applications that are "too big" for for your machine. Now whether this is due to poor application memory usage OR is due to poor-planning on the part of the system owner depends, in large part, on promises or expectations set by the developer or owner of the program.

Certainly, if I am running on a system with 128M of memory with a 650MHz mobile CPU, and load a full "suse 10.x" desktop with full features, I am asking that I be "shot in the foot". If a release (like suse10.2, or windows 98) says it will run best with 1GB-mem + a 1GHz processor and my machine has 2GB+a 2GHz processor and the release runs like a "dog" -- then I'd say it is the fault of the release packager (they made the choice of what packages to include 'by default').

Certainly if the *end user* chooses to run more applications than their computer can comfortably fit in memory, how can the application developer account for this.

...

Beagle should be scrapped and started over from the ground up, starting with the design assumption that it is to behave as an unobtrusive background process, not the current one which can take over the whole system with a "feed me" attitude as if the whole purpose for a computer and its data to even exist is to provide something for a beagle process to index.

----- Do you have documentation or direct knowledge of what the "design goals" were? If not, how do you know it wasn't designed that way?

Something the beagle developers cannot know is how their application will be installed by release packagers. One example of an outstanding 'bug' (or feature depending on interpretation) that can affect beagle performance is how it is run by 'cron.daily'. From my own experience, under 9.3, the default is to run cron.daily 24 hours after it last ran -- but if something delays it running "overnight" (like the machine being off or suspended) it will run within 15 minutes of the machine becoming active. IT WON'T WAIT until the 'middle of the night', as you might want. This has nothing to do with beagle or its developers.

Ideally, the beagle indexing process would run once (either at night, or immediately if needed), and then be able to monitor the filesystems and directories for changes using the "fam" (famd) package.

The "fam" function (and as extended for directories and/or devices) monitors when any change is done to its monitored file-system objects, then calls "listening" programs to process the new or changed objects as they are changed on disk. Ideally, you would then need no 'batch' updating, but such would be done in "bits" throughout the day as monitored files are changed.

That being said, if a system doesn't have the OS support or resources needed to run 'famd' without without degradation, the system will still be painful to use (shorthand: "be unusable").

Be careful about "global generalization" about a product being bad, though, though, just because it doesn't run well in a particular situation.

Linda

thanks, i think that about covers a broad spectrum of possible perceived problems... Howard -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Linda Walsh wrote:

...

...

...

The Saturday 2007-12-22 at 16:06 +0100, Anders Johansson wrote:

...

The real solution here is to find and fix the bug that causes beagle to allocate so much memory. It doesn't happen on all systems. ---. Without question, this is the best solution.

...

Anders Johansson wrote:

...

I wouldn't say "probably". It shouldn't be par for the course for an application to not check return values from memory allocation functions

Aaron Kulkis wrote:

...

As I said earlier... the whole thing is poorly written.

---

And you say this based on???

It's performance. It's SUPPOSED to be an unobtrusive background process, but can cripple a high-end machine through extreme resource-hogging behavior. Unfriendly behavior is the very definition of poor code.

Do you have _any_ expertise in the source?

Not at all, but that's not even the issue. We're not talking about "there's a faster way to sort this data" sorts of tweaks...we're talking about code which is widely known to effectively cripple any system it runs on, due to nothing more than the files it's handling, and how many there are.

(if you do, sorry, but your attitude is not productive). It _appears_ you know nothing about how it is written but are basing your opinion on its behavior in certain configurations.

I'm basing my evaluation on how it performs, and its impact on system performance....which is the ultimate standard of judging any code as to whether it is to be judged "good enough" or not.

This is why I made a comment about *not* using "swap" on a system -- if you are using swap on any regular basis (my threshhold is using swap, *anytime*, during 'normal' day-to-day usage), you are running applications that are "too big" for for your machine. Now whether this is due to poor application memory usage OR is due to poor-planning on the part of the system owner depends, in large part, on promises or expectations set by the developer or owner of the program.

I've got 2 GB of DDR2 on this machine, and 3 GB of swap, on a Centrino Core Duo running at 800 MHz with two internal 100 GB SATA drives, of which 140 GB is used by my SuSE installation. And a running beagle process makes this machine absolutely unusable....even without a GUI.

Certainly, if I am running on a system with 128M of memory with a 650MHz mobile CPU, and load a full "suse 10.x" desktop with full features, I am asking that I be "shot in the foot". If a release (like suse10.2, or windows 98) says it will run best with 1GB-mem + a 1GHz processor and my machine has 2GB+a 2GHz processor and the release runs like a "dog" -- then I'd say it is the fault of the release packager (they made the choice of what packages to include 'by default').

Certainly if the *end user* chooses to run more applications than their computer can comfortably fit in memory, how can the application developer account for this.

Beagle will grow and grow and grow until it uses all available swap. It appears that the only way to satisfy beagle's appetite appears to be to have enough memory to load up all of your home directory tree into it. But I don't know of any motherboard sold for under US $10,000 that can accomodate 60 GB of ram.

...

Beagle should be scrapped and started over from the ground up, starting with the design assumption that it is to behave as an unobtrusive background process, not the current one which can take over the whole system with a "feed me" attitude as if the whole purpose for a computer and its data to even exist is to provide something for a beagle process to index.

---

Do you have documentation or direct knowledge of what the "design goals" were? If not, how do you know it wasn't designed that way?

I'm saying that the design goals either were not met, or they were utterly inappropriate.

Something the beagle developers cannot know is how their application will be installed by release packagers. One example of an outstanding 'bug' (or feature depending on interpretation) that can affect beagle performance is how it is run by 'cron.daily'. From my own experience, under 9.3, the default is to run cron.daily 24 hours after it last ran -- but if something delays it running "overnight" (like the machine being off or suspended) it will run within 15 minutes of the machine becoming active. IT WON'T WAIT until the 'middle of the night', as you might want. This has nothing to do with beagle or its developers.

I'm likely to be using this computer at all hours of the day and night... I wake up, get an idea, do something, and then go back to sleep...

Ideally, the beagle indexing process would run once (either at night, or immediately if needed), and then be able to monitor the filesystems and directories for changes using the "fam" (famd) package.

fam is another thing I've banished from my installations, for similar reasons. Maybe a good idea but it too suffers from poor implementation.

The "fam" function (and as extended for directories and/or devices) monitors when any change is done to its monitored file-system objects, then calls "listening" programs to process the new or changed objects as they are changed on disk. Ideally, you would then need no 'batch' updating, but such would be done in "bits" throughout the day as monitored files are changed.

That being said, if a system doesn't have the OS support or resources needed to run 'famd' without without degradation, the system will still be painful to use (shorthand: "be unusable").

I'm a VERY strong advocate of loading up on memory, even if it means cutting into the CPU budget (and losing a few MHz), because page-faults to/from swap are VERY expensive in terms of performance...

Be careful about "global generalization" about a product being bad, though, though, just because it doesn't run well in a particular situation.

While I don't doubt that beagle does run acceptably in some instances, I've never seen it do so.

Linda

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2007-12-22 at 18:09 +0100, Anders Johansson wrote:

...

Actually, it helps solve it, sometimes. The application crashes, probably

I wouldn't say "probably". It shouldn't be par for the course for an application to not check return values from memory allocation functions

That's not what I said. Look again: ] The application crashes, probably ] with an error, maybe a core dump or a backtrace, and it can be examined. There is a comma after the "crashes". I didn't say that it "probably crashes". I said that it will crash, and then probably will produce an error message. The idea is that an application that has a memory hole and uses a lot of memory doesn't crash, but by running with an "ulimit" it will crash when it hits the limit, ant then the error, coredump, or backtrace can be examined. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHbasrtTMYHG2NR9URArIgAKCUI9NyG9hRhD25ZuonZQ/BHlMALgCgkXWu eJY+OmRrUbhlqSr1oM7NPgw= =ND5g -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Anders Johansson wrote:

On Sunday 23 December 2007 01:26:08 Carlos E. R. wrote:

...

The Saturday 2007-12-22 at 18:09 +0100, Anders Johansson wrote:

...

...

Actually, it helps solve it, sometimes. The application crashes, probably I wouldn't say "probably". It shouldn't be par for the course for an application to not check return values from memory allocation functions That's not what I said. Look again:

] The application crashes, probably ] with an error, maybe a core dump or a backtrace, and it can be examined.

There is a comma after the "crashes".

I didn't say that it "probably crashes". I said that it will crash, and then probably will produce an error message.

The idea is that an application that has a memory hole and uses a lot of memory doesn't crash, but by running with an "ulimit" it will crash when it hits the limit, ant then the error, coredump, or backtrace can be examined.

Well, the idea might work, but I still say that you're too dogmatic. Even an application that forgets to free() memory can still test the return code from malloc() properly. It's not a given that it will crash. It might just exit normally, without a core being produced]

If it doesn't check return values from malloc() (or something which calls malloc()), it WILL crash due to a segmentation fault (trying to write to structure members through a structure-pointer which is NULL or -1. If it does check return it can still crash, but that would be due to other problems. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Aaron Kulkis wrote:

I just checked the man page for ulimit, and did a search for the string "swap" and it came up empty... so it looks like ulimit might not help here....although ulimit -v can set an upper limit on virtual memory,

You want to cap virtual memory usage, since virtual memory size is the total of a process's physical memory and swap-space use. L -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

kanenas@hawaii.rr.com wrote:

On Wednesday 19 December 2007 01:02:56 pm Aaron Kulkis wrote:

...

ah... ionice seems to be a new invention. I'll give it a try when I build a new system this month.

Even if one nices and ionices beagle, there still is the matter of swap space getting filled. Usually it is when that happens when ugly thoughts against the developers spring to life. is there a "swapnice" or something for control of max swap space an app can use?

not on my 10.1 system. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 * Linda Walsh <suse@tlinx.org> [12-22-07 18:18]:

I just checked suse10.2 packages...

If you have the "ionice" program (/usr/bin/ionice) installed under SuSE-10.3 OR -10.2, daily beagle indexing will automatically use it to set the beagle-indexing process to lowest (idle) priority using the command format "ionice -c 3". The relevant lines in file /etc/cron.daily/beagle-crawl-system (fr suse10.3, beagle-0.2.12-28): lines 65-70: 65 IONICE=`which ionice 2>/dev/null` 66 if [ -n "$IONICE" ]; then 67 IONICE="$IONICE -c 3" 68 fi 69 70 eval nice -n 19 $IONICE su -s /bin/bash $CRAWL_USER -c \"MONO_SH ARED_DIR=$MONO_SHARED_DIR /usr/sbin/beagle-build-index --target /var/cache/b eagle/indexes/$CRAWL_INDEX_NAME $OPTIONS $CRAWL_PATHS\" > /dev/null 2>&1 71 fi

(don't know about 10.1, SLED, or 10.0 as I don't have those packages locally accessible, but shouldn't be too hard for someone to verify)...

10.1 is the same - -- Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535 @ http://counter.li.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFHbZ98ClSjbQz1U5oRAm/eAKCDNriXzNmnCaMGJUWGSPLLEagOhgCfb0/l iX7RAIZ0r6hvxWroWeI330o= =8caX -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Kevin Dupuy wrote:

On Mon, 2007-12-17 at 10:53 -0500, Aaron Kulkis wrote:

...

Gary Baribault wrote:

...

Hi all,

Anyone else seeing Beagle really kill performance? I have disabled it and my machine finally is perky, but every now and then, I find it in memory again. How do I arange it to chew up less memory and CPU or kill it once and for all? You can't.

It's one of the stupidest pieces of software that I've ever seen in my entire 27 years of computing. Even putting it at the lowest priority "nice" value doesn't help, because the damn thing floods the disk drive with a constant stream of disk-head seeks, which interferes with any other process's attempts to use the disk drive by making it basically, stand in line with all of beagle's worthless disk I/O requests.

The maintainers for beagle should be taken out and kneecapped, or beat about the head with a police baton.

Every day

Until they remove every trace of it from human existence, except for snippets preserved for teaching purposes, under the topic of "DO NOT DO THESE THINGS in a background services programs"

I'm starting to get tired of the hating on Beagle's devs.

Excuse me...has anyone really expressed HATRED towards the Beagle dev... Or have we just been noting that the software suffers from a VERY SERIOUS DEFICIENCY -- see "Constructive Criticism" "hating on" should be banished from the English language, because it is so widely abused by people who can't handle the fact that not everything or everybody is worthy of pure, unqualified praise now and forever. Most of the time when it is used, as in the posted example, it's just a sign of trying to suppress valid criticism. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Linda Walsh wrote:

Aaron Kulkis wrote:

...

Kevin Dupuy wrote:

...

On Mon, 2007-12-17 at 10:53 -0500, Aaron Kulkis wrote:

...

The maintainers for beagle should be taken out and kneecapped, or beat about the head with a police baton.

Every day

I'm starting to get tired of the hating on Beagle's devs.

Excuse me...has anyone really expressed HATRED towards the Beagle dev...

---

Uh...Aaron, YES! :-) Yes. You are saying they should be violently beaten every day.

That would just be motivation to improve! -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

I made a filter marking messages by Aaron Kulkis as read some time ago, but can he please be placed under moderation for making appeals to violence and torture ? I understand the stresses placed on someone paid to wage war, kill and torture people in Iraq and other places, but not every participant glorifies the violence and that level of hate does not need to infect open source software mailinglists. Kind regards Philippe -- Aaron Kulkis wrote:

Gary Baribault wrote:

...

Hi all,

Anyone else seeing Beagle really kill performance? I have disabled it and my machine finally is perky, but every now and then, I find it in memory again. How do I arange it to chew up less memory and CPU or kill it once and for all?

You can't.

It's one of the stupidest pieces of software that I've ever seen in my entire 27 years of computing. Even putting it at the lowest priority "nice" value doesn't help, because the damn thing floods the disk drive with a constant stream of disk-head seeks, which interferes with any other process's attempts to use the disk drive by making it basically, stand in line with all of beagle's worthless disk I/O requests.

The maintainers for beagle should be taken out and kneecapped, or beat about the head with a police baton.

Every day

Until they remove every trace of it from human existence, except for snippets preserved for teaching purposes, under the topic of "DO NOT DO THESE THINGS in a background services programs"

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

On Sat 12 January 08 00:11, Philippe Landau wrote:

I made a filter marking messages by Aaron Kulkis as read some time ago, but can he please be placed under moderation for making appeals to violence and torture ?

I understand the stresses placed on someone paid to wage war, kill and torture people in Iraq and other places, but not every participant glorifies the violence and that level of hate does not need to infect open source software mailinglists.

Got yourself enough tissues for all those tears? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stevens schreef:

On Saturday 12 January 2008 00:11, Philippe Landau wrote:

...

I made a filter marking messages by Aaron Kulkis as read some time ago, but can he please be placed under moderation for making appeals to violence and torture ?

Why? Sometimes that is the best method to get someone's attention and cooperation. It worked for Al Capone in Chicago. It might even work on programmers. From what I have seen of some code, it is worth a try.

That is what i sometimes think also...

...

I understand the stresses placed on someone paid to wage war, kill and torture people in Iraq and other places, but not every participant glorifies the violence and that level of hate does not need to infect open source software mailinglists.

Where did that crap come from? Is Aaron a merc? I bet that if he was, he wouldn't be on this list 'cause he would be making so much money he could be having real fun instead of being reduced to playing with computers.

Some of us also get drafted?

I would expect cultural differences on a world-wide forum such as this one. I would also think that the other members would be able to grasp those differences, respect them for what they are and ignore any that offend. But maybe I expect too much.

Fred

Not if it was up to me, this sounds completely sane and reasonable to me....

==========

- -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.24-rc6-git11-3-default x86_64 Huidige gebruiker: monkey9@tribal-sfn2 Systeem: openSUSE 11.0 (x86_64) Alpha0 KDE: 3.5.8 "release 31" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHiO0QX5/X5X6LpDgRAiuBAKDcTK6U1gEK+423l7iM2NQJLlO/WgCdGEET SgKppOBR/wcn6A//1lHYOhA= =7Omr -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dog Walker schreef:

On Jan 12, 2008 8:38 AM, M9. <monkey9@iae.nl> wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Stevens schreef:

...

On Saturday 12 January 2008 00:11, Philippe Landau wrote:

...

I made a filter marking messages by Aaron Kulkis as read some time ago, but can he please be placed under moderation for making appeals to violence and torture ?

[...]

I think Kulkis, Druid, et al. are ++diaperfull cyberbrats who are banging their keyboards against their highchairs for attention. Having the list killfile them would be welcome.

Are you both realy as pityfull as you seem? Or are you just sick-joking? - -- Have a nice day, M9. Now, is the only time that exists. OS: Linux 2.6.24-rc6-git11-3-default x86_64 Huidige gebruiker: monkey9@tribal-sfn2 Systeem: openSUSE 11.0 (x86_64) Alpha0 KDE: 3.5.8 "release 31" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHiQSaX5/X5X6LpDgRAp7XAJ9YyRS86oHJGrTWkR3Ltcf753EL2wCfbWZ7 Jo8H0zpr6UclVAalN9JvtAI= =gule -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org