Hi Robert, is there any news or idea about this issue? Is it a common issue that the WS-Security standard does not define the order of encrypting and signing and some server are using it differently? Without passing the TLS layer it would not be possible to use gSOAP for this kind of services. Best regards, Massimo
I was not able to reproduce that issue with geodesic and switched to that one temporarilly. I just don't like it as much as the really slick helios. P.S.: Ok, that geodesic code is part of xscreensaver package, not the rss-glx.
I was not able to reproduce that issue with geodesic and switched to that one temporarilly. I just don't like it as much as the really slick helios.
I can reproduce that for a long time now with my favourite screensaver helios: https://bugs.gentoo.org/show_bug.cgi?id=478074 Just every time the screensaver starts it leaves processes behind consuming CPU: # pgrep -alf helios 7337 helios -r -i 10 -s 10 -e 1 -a 1 -S 1 -c 1 -b 6 -w 7338 helios -r -i 10 -s 10 -e 1 -a 1 -S 1 -c 1 -b 6 -w 7339 helios -r -i 10 -s 10 -e 1 -a 1 -S 1 -c 1 -b 6 -w While kill doesn't work I almost always need to do killall -9 helios after leaving screensaver.
From the documentation I understand that preload does fill the cache with objects right after starting the service that is usually at boot time. Does preload drop objects that have been served? Like starting a huge binary application means it gets served by preload's cache. But after that the binary object could be dropped from preload's cache to free some memory, until the process is closed. Is that already done in the implementation of preload?
I installed preload on Gentoo and wondered about the default setting of memcached = 0. That doesn't do anything I learned from the logs after setting PRELOAD_VERBOSITY=10. But setting memcached to something like 30 make preload start to work. Is there any reason for the default setting 0?
Respect web proxy environment settings
Validation constraint violation: syntax error in element 'http:address'