00:16 | Parker955_Away is now known as Parker955 | |
00:41 | Parker955 is now known as Parker955_Away | |
01:29 | vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving) | |
01:34 | darthanubis has joined IRC (darthanubis!~darthanub@cpe-66-61-35-95.neo.res.rr.com) | |
04:28 | telex has left IRC (telex!~telex@freeshell.de, Ping timeout: 260 seconds) | |
04:35 | telex has joined IRC (telex!~telex@freeshell.de) | |
04:40 | telex has left IRC (telex!~telex@freeshell.de, Ping timeout: 260 seconds) | |
04:45 | Parker955_Away is now known as Parker955 | |
04:50 | telex has joined IRC (telex!~telex@freeshell.de) | |
05:13 | Parker955 is now known as Parker955_Away | |
05:26 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
05:35 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Read error: Connection reset by peer) | |
05:35 | alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg) | |
05:39 | mmetzger has left IRC (mmetzger!~mmetzger@99-71-214-196.lightspeed.mdldtx.sbcglobal.net, Ping timeout: 248 seconds) | |
05:41 | mmetzger has joined IRC (mmetzger!~mmetzger@99-71-214-196.lightspeed.mdldtx.sbcglobal.net) | |
06:21 | alkisg1 has left IRC (alkisg1!~alkisg@ubuntu/member/alkisg, Ping timeout: 255 seconds) | |
06:37 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
07:05 | alkisg1 has joined IRC (alkisg1!~alkisg@ubuntu/member/alkisg) | |
07:06 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 265 seconds) | |
07:20 | alkisg1 is now known as alkisg | |
07:44 | ricotz has joined IRC (ricotz!~rico@p5B2AB992.dip.t-dialin.net) | |
07:44 | ricotz has joined IRC (ricotz!~rico@ubuntu/member/ricotz) | |
07:51 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
07:57 | bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) | |
08:26 | highvoltage has left IRC (highvoltage!~highvolta@ubuntu/member/highvoltage, Read error: Connection reset by peer) | |
08:27 | highvoltage has joined IRC (highvoltage!~highvolta@ubuntu/member/highvoltage) | |
08:41 | klausade has joined IRC (klausade!~klaus@cm-84.215.156.145.getinternet.no) | |
08:46 | andygraybeal_ has joined IRC (andygraybeal_!~andy@h82.200.130.174.dynamic.ip.windstream.net) | |
08:47 | markit has joined IRC (markit!~marco@88-149-177-66.v4.ngi.it) | |
08:54 | komunista has joined IRC (komunista!~slavko@adsl-195-168-234-074.dynamic.nextra.sk) | |
09:17 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 272 seconds) | |
09:51 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
10:06 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
10:22 | <muppis> What?
| |
10:22 | I powered ltsp server off by mistake. Powered on and client just asked root's password and continued working like nothing happened.
| |
10:23 | Well, it's a fat client.
| |
10:49 | alkisg_android has joined IRC (alkisg_android!~AndChat66@athedsl-152587.home.otenet.gr) | |
10:54 | komunista has left IRC (komunista!~slavko@adsl-195-168-234-074.dynamic.nextra.sk, Quit: Leaving.) | |
11:00 | alkisg_android has left IRC (alkisg_android!~AndChat66@athedsl-152587.home.otenet.gr, Ping timeout: 245 seconds) | |
11:05 | <andygraybeal_> muppis, the network shares might have been disconnected
| |
11:05 | i mean, i don't know.. but i would worry about that ;)
| |
11:21 | andygraybeal_ has left IRC (andygraybeal_!~andy@h82.200.130.174.dynamic.ip.windstream.net, Ping timeout: 245 seconds) | |
11:29 | alkisg_android has joined IRC (alkisg_android!~AndChat66@athedsl-152587.home.otenet.gr) | |
11:33 | <muppis> andygraybeal, actually afterwards happened what I expected. As nbd disconnected, it didn't re-establish connection and nothing new was unable to start.
| |
11:34 | alkisg_android has left IRC (alkisg_android!~AndChat66@athedsl-152587.home.otenet.gr, Ping timeout: 265 seconds) | |
11:57 | komunista has joined IRC (komunista!~slavko@adsl-195-168-234-074.dynamic.nextra.sk) | |
12:03 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
12:06 | <alkisg> muppis: the problem mostly isn't nbd but sshfs. nbd can reconnect / if the server is only missing for a little bit, but sshfs won't reconnect /home/username, so apps that require ~ access will fail.
| |
12:17 | <markit> alkisg: just to know... is this coming week that you (hopefully) can have a look at KDE with ltsp, or the next one (22-28 october)?
| |
12:19 | <muppis> alkisg, so if I got a root shell in screen 02 I should be able to reconnect sshfs as well?
| |
12:45 | bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) | |
13:00 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
13:03 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
13:16 | komunista has left IRC (komunista!~slavko@adsl-195-168-234-074.dynamic.nextra.sk, Quit: Leaving.) | |
14:08 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
14:10 | risca has joined IRC (risca!~risca@193.11.200.69) | |
14:22 | <alkisg> markit: I think that adding "-threads" to vnc increases performance a lot
| |
14:22 | Can you try it in your schools some time?
| |
14:23 | (I'm talking about broadcasting teacher screen from epoptes)
| |
14:23 | I tried it at work with only 2 clients, and the bandwidth has gone from 120 mbps to 180 mbps
| |
14:24 | file: /usr/share/pyshared/epoptes/ui/gui.py
| |
14:24 | self.vncserver = subprocess.Popen(['x11vnc', '-noshm', '-nopw', '-threads'
| |
14:24 | That's the change you need to do to test it, and open epoptes after that
| |
14:29 | FGXR6 has left IRC (FGXR6!~phantom@ppp121-44-8-89.lns20.syd6.internode.on.net, Ping timeout: 240 seconds) | |
14:32 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 252 seconds) | |
14:45 | <markit> alkisg: thanks a lot, but my main problem now is KDE as fat... without that I have nothing to deploy and use with epoptes ;P
| |
14:46 | in any case I will test your suggestion as soon as possible too... is an interesting jump in performances
| |
14:46 | <alkisg> Hmm it will take me some hours to install kde, ltsp-pnp etc and debug fat clients... let me see when I can fit that in my schedule... :-/
| |
14:47 | <markit> alkisg: yep, I'm sorry to put that burden on you, but I've tried to understand what's going wrong and I stopped to the permission stuff
| |
14:48 | and probably if help me fix it will take much more time ;P
| |
14:48 | I'm a bit ashamed of asking you, sincerely
| |
14:49 | * alkisg might do that today, otherwise I'm afraid I'll postpone it too far in the future :D | |
14:49 | <markit> but I'm in a impasse
| |
14:49 | oh, I cross my fingers then and stop talking distracting you ;P
| |
14:49 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
14:52 | <alkisg> markit: will you be around in case I have questions about what's wrong with your setup?
| |
14:53 | (to put me up to speed with the problems and the paths you've tried so far...)
| |
14:53 | <markit> as much as I can.. I've to go out with my wife for about 30 minutes (later), the rest I'm here
| |
14:53 | <alkisg> Cool
| |
14:53 | OK, starting...
| |
14:54 | <markit> hahaha, would be ridicolous overwise
| |
14:54 | risca has left IRC (risca!~risca@193.11.200.69, Ping timeout: 272 seconds) | |
15:00 | <alkisg> markit: on a typical KDE system (non LTSP), where is the big user cache stored? Under $HOME or in /var/cache?
| |
15:00 | <markit> in /var/tmp
| |
15:00 | and has kdecache-username
| |
15:00 | <alkisg> Ty, checking...
| |
15:00 | <markit> while in $HOME/.kde you have a symlink
| |
15:00 | in the form of cache-HOSTNAME to that
| |
15:01 | so if you connect from a different host each day, you will have many symlink but everyone pointing to the same /var/tmp
| |
15:01 | <alkisg> markit: and you prefer to use nfs or sshfs?
| |
15:02 | <markit> well, nfs should put less pressure on CPU
| |
15:02 | so nfs
| |
15:02 | <alkisg> markit: I've got /var/tmp/kdecache-artemis, but also many /tmp/var/ kdecache-artemisri8ZZk, with some random chars
| |
15:02 | Any idea why those are there?
| |
15:03 | <markit> yep, more or less the /var/tmp is intended to survive reboots
| |
15:03 | while /tmp not
| |
15:03 | <alkisg> But why multiple dirs for the same user?
| |
15:03 | Sorry
| |
15:03 | I meant /var/tmp
| |
15:04 | Instead of /tmp/var/kdecache-artemisri8ZZk, I meant var//tmp/kdecache-artemisri8ZZk
| |
15:04 | I.e. in the /var/tmp/ folder, I have 5 directories for the same user, artemis
| |
15:04 | <markit> because if you put under /var/tmp it will stay there
| |
15:04 | kde wants /tmp stuff to be very "temp", so don't survive reboot
| |
15:05 | <alkisg> No I'm talking about something different
| |
15:05 | <markit> while in /var/tmp they put "optimizations"
| |
15:05 | <alkisg> Forget about /tmp, it was a typo
| |
15:05 | <markit> ok
| |
15:05 | <alkisg> I was always talking about /var/tmp
| |
15:05 | <markit> oh
| |
15:05 | I see
| |
15:05 | ok, if it fails
| |
15:05 | <alkisg> So, I have 5 kdecache-artemis* folders for the same artemis user
| |
15:05 | <markit> tries a different random name
| |
15:05 | <alkisg> Meh
| |
15:05 | <markit> if you boot stand alone
| |
15:05 | you have ONLY /var/tmp/kdecache-artemis
| |
15:05 | if the process fails using it
| |
15:06 | <alkisg> It's my daughter's netbook, it's standalone
| |
15:06 | <markit> it generates a random /var/tmp/kdecache-artemis8sdfa
| |
15:06 | I've only kdecache-marco
| |
15:06 | in my debian sid... I've seen that behaviour only with ltsp
| |
15:06 | <alkisg> So for some reason it failed sometime... ok, anyway, moving on...
| |
15:06 | <markit> you can safely remove that stuff
| |
15:07 | (of course not while you are logged in kde)
| |
15:07 | and remove .kde links to it, when you relog, will be generated
| |
15:07 | or create a new user
| |
15:07 | so you will see a "clean" situation
| |
15:07 | <alkisg> I'm trying with a new user, yeah... it got 94Mb on the first login
| |
15:08 | <markit> (most of what I'm saying are my guesses based of what I saw, nothing documented AFAIK)
| |
15:08 | <alkisg> That's too much to have for _every_ login, yeah, we need to reuse that caching
| |
15:08 | <markit> it's reused if everything works (I mean in normal desktop, no ltsp)
| |
15:09 | but there is something broken, so in ltsp I think is regenerated multiple times -> 600MB
| |
15:09 | of network traffic
| |
15:09 | <alkisg> I'll try with the default sshfs first because I've already ran `ltsp-update-image -c /` and I forgot to install nfs-comon...
| |
15:09 | <markit> sure, I'm happy with everything that works fine
| |
15:09 | I think that when you will find the problem, will apply to nfs as well
| |
15:11 | <alkisg> Meh, /home/user/.local/share/akonadi => 150 Mb on first loign
| |
15:11 | login
| |
15:11 | Anyways
| |
15:14 | Wow also vnc has problems with kwin, it first clears the whole background with black and then draws the screen again
| |
15:20 | <markit> alkisg: I've disabled akonadi with a global setting, let me find it
| |
15:20 | <alkisg> markit: nah, don't bother
| |
15:20 | https://bugs.kde.org/show_bug.cgi?id=283921
| |
15:20 | Bother with that one instead :D
| |
15:20 | 81mb for caching theme settings?!!!
| |
15:20 | Comment there, have people vote for it etc
| |
15:21 | <markit> sigh! and more and more devs will have SSD, so the problem will only become bigger and bigger I fear
| |
15:21 | <alkisg> No, it's the opposite of that
| |
15:21 | If they use tmpfs and cache grows too large, they'll bump into problems themselves
| |
15:21 | <markit> FOSS is not driven by rational priorities, but devs moods and "what looks cool" too much
| |
15:22 | <alkisg> Sure, but sometimes they see the problems that are caused, and take time to solve them
| |
15:22 | * markit takes note | |
15:22 | <markit> alkisg: well, isn't ridicolous that they had too much I/O, and the solution was not to reduce "un needed I/O" but to create a cache?
| |
15:22 | that's why I'm not optimistic
| |
15:22 | <alkisg> E.g. you might find that this doesn't happen with upstream KDE, but only when using custom themes, e.g. kubuntu
| |
15:22 | <markit> but let's go on
| |
15:23 | ok
| |
15:23 | <alkisg> So if it doesn't happen for them because they use upstream KDE, they won't care much
| |
15:23 | * alkisg is waiting for ltsp-update-image to finish in the atom-based notebook... | |
15:24 | <alkisg> markit: what's happenning with nfs and cross-mount symlinks?
| |
15:24 | <markit> that cross-mount does not work, AFAIR
| |
15:25 | even if you try with ln -s
| |
15:25 | <alkisg> E.g. /home/artemis/.kde/cache-pc pointing to /var/tmp/kdecache-artemis, that won't work?
| |
15:25 | Even if both of them are mounted from the same server etc?
| |
15:25 | <markit> not as far as I remember, and sure not in the ..../startkde that uses lnusertemp command
| |
15:25 | <alkisg> Can I manually run lnusertemp?
| |
15:26 | <markit> and my conclusion (and the log I got putting a > /tmp/logme) was that the files are owned by 65585 and not user id
| |
15:26 | yep, let me find it
| |
15:26 | (is not in the path, in starkde you see how it's pat is got)
| |
15:26 | <alkisg> Yup got it
| |
15:26 | markit: ok &
| |
15:26 | ^
| |
15:27 | <markit> alkisg: /usr/lib/kde4/libexec/lnusertemp
| |
15:27 | <alkisg> markit: lnusertemp creates the dir and the symlinks, right?
| |
15:27 | And then the programs like plasma put their cache in it...
| |
15:27 | <markit> not sure, seems so
| |
15:28 | yes, should be so
| |
15:28 | I've put a if "$lnusertemp" $resource >> /tmp/lnuser.log 2>&1; then
| |
15:28 | and then checked the content of that log file
| |
15:28 | <alkisg> Hmm no there needs to be some suid program that creates the dir
| |
15:28 | <markit> root@ltsp102:~# cat /tmp/lnuser.log
| |
15:28 | Error: "/home/marco/.cache/kdecache-marco" is owned by uid 65534 instead of uid 1001.
| |
15:28 | Error: "/home/marco/.cache/kdecache-marcoKLWL71" is owned by uid 65534 instead of uid 1001.
| |
15:29 | <alkisg> One idea there:
| |
15:29 | They might have a daemon create the dir as root, and then chown it
| |
15:29 | If so, when you export with nfs and root_squash, the file won't be owned by root
| |
15:29 | It will be owned by nobody
| |
15:30 | So to make KDE work better over nfs, they should create the file directly with the correct owner
| |
15:30 | markit: do you have your /etc/exports handy?
| |
15:30 | Or is it at school?
| |
15:31 | <markit> it's on the VM of the PC my children is using with the second boot
| |
15:31 | but I have some note about it
| |
15:31 | <alkisg> OK no worries it doesn't matter much
| |
15:31 | <markit> maybe...
| |
15:31 | and to avoid 2 NFS mounts I've done
| |
15:31 | <alkisg> I'm guessing you're using root_squash, and it's the right thing to do
| |
15:32 | The problem is in the KDE code, they'd need to fix that
| |
15:32 | <markit> in /etc/profile
| |
15:32 | export KDEVARTMP="$HOME/.cache"
| |
15:32 | <alkisg> What does that do?
| |
15:32 | Can you control that you want to use $HOME/.cache instead of /var/tmp?
| |
15:32 | <markit> it should create kdecache-user in $HOME/.cache
| |
15:32 | instead of in /var/tmp
| |
15:32 | <alkisg> Cool, let me try...
| |
15:33 | <markit> but seems not to work much better
| |
15:33 | <alkisg> That sounds much better than messing with symlinks
| |
15:33 | <markit> (of course, you better remove .kde and /var/tmp if you try, to be sure that something different happens)
| |
15:33 | <alkisg> I'll try that one first
| |
15:33 | <markit> good
| |
15:34 | <alkisg> Yup, works fine
| |
15:36 | <markit> good, but iftop traffic?
| |
15:37 | (btw, as far as I remember, it did not worked fine and kdecache-user was created under .kde and not under .cache... but I could be wrong if there works fine)
| |
15:38 | (and I had still the permission problem, so 600MB of iftop traffic)
| |
15:40 | <alkisg> .profile might be too late for it
| |
15:40 | I'm putting it to /etc/environment so that it's read by pam
| |
15:41 | * markit ignores all this stuff... what a bad sysadmin he is | |
15:41 | <alkisg> Nah $HOME doesn't work in /etc/environment.... will look for some other pam-based way that also sets $HOME...
| |
15:42 | <markit> ah, yes, that's a problem too... $HOME must be set
| |
15:42 | I'm wondering why kde doc says about environ variables, but does not spend just one line of doc telling WHERE is the proper location to change
| |
15:43 | maybe is so obvious... :(
| |
15:45 | <alkisg> For the test, I'm putting it to ~/.pam_environment
| |
15:45 | I'll look later for the proper file to put that
| |
15:46 | But there I'm pretty sure it gets set early enough
| |
15:46 | Without $HOME, completely hardcoded, /home/artemis/.cache
| |
15:47 | ltsp-update-image done, rebooting...
| |
15:49 | ${HOME} isn't yet available in pam_env.conf either... I'll check if ${USER} is, so that we set it to /home/${USER}/.cache
| |
15:50 | markit: so, the target is: first login => 60 seconds or whatever, second login => less than 30 seconds, right?
| |
15:50 | From a fat client...
| |
15:52 | <markit> yep, that would be more or less desktop performance
| |
15:52 | but also a network traffic of < 100MB would be a 6x improvement
| |
15:52 | now it generates 600MB at EVERY login
| |
15:52 | <alkisg> From pxelinux to kdm, 45 seconds
| |
15:53 | <markit> kdm to plasma could take as much then
| |
15:54 | the problem is that with 600MB traffic, one or 2 clients are "fast enough", but when you have 10 or 24, it takes... 30 minutes or more
| |
15:55 | <alkisg> 110 secs, 450 mb traffic or more, I didn't measure the traffic for the first few seconds
| |
15:56 | Let's see the cache path, although I forgot to do the pam change in the chroot...
| |
15:56 | Meh no it's still causing traffic, at 700mb now
| |
15:56 | Stopped at 765
| |
15:57 | <markit> yep, like here
| |
15:57 | at least we have the same situation, is a good starting point (want to be optimistic, lol)
| |
15:58 | <klausade> markit: a few years ago we looked at upgrading thousands and thousands of thin- and diskless-clients from kde3 to kde4. We gave up. what ever we did, performance was horrible, compared to kde3. We switched to xfce4, the best thing ever.
| |
15:58 | <alkisg> Ermmm...
| |
15:58 | Cache is fine, all under .kde, nothing in /var/tmp
| |
15:58 | /tmp is also almost empty
| |
15:58 | ...I don't know what cause the traffic!
| |
15:58 | ...trying second login...
| |
15:59 | Ah btw since I put it to /home/username/.pam_environment, it's valid for both server+fat client, and that's why it worked for me without setting it globally somewhere
| |
16:00 | <markit> klausade: the problem is that I installe kde everywhere in 3 schools, from smartboard to teacher's laptop etc and trained them to use it. I can't say "oh, was just a joke, let's change UI" now :(
| |
16:01 | klausade: in thin works like a charm, and in fat too.... in my test lab with 2 clients! I deploied the first time in a 24 class and was a nightmare, but was only 2 months ago
| |
16:01 | <alkisg> markit: success, second login at 25 seconds, 50mb traffic
| |
16:01 | <markit> wow!!!
| |
16:01 | <alkisg> Ah after login it's climbing again, let me see where it stops...
| |
16:01 | <markit> I do hope is something easy to setup and does not require kde re-desigh from the ground up ;P
| |
16:02 | <alkisg> 151mb
| |
16:02 | <markit> mmm
| |
16:02 | <alkisg> But that's not about the cache
| |
16:02 | That's when the sound is played
| |
16:02 | <markit> maybe nepomuk?
| |
16:02 | you did not disabled?
| |
16:02 | <alkisg> No I'm using default installation
| |
16:02 | <markit> I've seen a lot of traffic by kmix in the past
| |
16:02 | mmm default install should have nepomuk ENABLED
| |
16:03 | if you check the systemsettings
| |
16:03 | write "nepomuk" and see in what panel is set up
| |
16:03 | <alkisg> OK, let me google for nepomuk first...
| |
16:03 | <markit> (desktop search)
| |
16:04 | by default it uses mysql, and it generates a 100MB database
| |
16:04 | ops, that is akonadi sorry
| |
16:04 | I set akonadi to use sqlite3 instead
| |
16:04 | dropping the wasted space a lot
| |
16:04 | <alkisg> Nepomuk also is a meta-info caching framework... ok let me check the disk usage
| |
16:05 | <markit> yep, akonadi is a sort of "storage backend"
| |
16:05 | <alkisg> 95M .cache, 23M .kde, 149M .local
| |
16:05 | <markit> (and we are back to those "cool features" only 2% uses and afflict 98% of users)
| |
16:06 | sudo aptitude install akonadi-backend-sqlite
| |
16:06 | edit /etc/akonadi/akonadiserverrc
| |
16:06 | [eneral]
| |
16:07 | Driver=QSQLITE3
| |
16:07 | and remove .kde in the user home so takes that global parameter
| |
16:07 | <alkisg> nepomuk => soprano-virtuoso.db => 10 mb
| |
16:07 | <markit> since .local/share/akonadi has a 100MB usage, right?
| |
16:07 | yep, but I think nepomuk keeps hunting for files and content to reindex
| |
16:08 | so makes no good to performance as well
| |
16:08 | <alkisg> markit: any easy way to completely disable akonadi and nepomuk?
| |
16:08 | <markit> from systemsettings?
| |
16:08 | in any case, the .local usage should be for the first login only
| |
16:08 | <alkisg> Sure, if they can be completely disabled there...
| |
16:08 | Going there to check
| |
16:09 | <markit> well, I think that they survive as processes, but don't do any work
| |
16:09 | <alkisg> No something else is updating its files on subsequent logins as well
| |
16:09 | <klausade> markit: /me thinks of dead horses and flying pigs when someone mentions kde4 ....
| |
16:09 | <markit> ah :(
| |
16:09 | klausade: lol
| |
16:09 | <alkisg> So I don't see /home/username growing, but I do see 150 mb traffic on logins, which is a bit much
| |
16:09 | Nothing terrible though, it's not 750mb anymore
| |
16:10 | <markit> yep, is a good starting point for further refinement
| |
16:10 | since kde people hearing of 700MB think that something on the LTSP side is broken
| |
16:10 | and don't take it in consideration
| |
16:11 | btw, in nepomukserverrc under (somewhere .kde or home, don't remember) you can set
| |
16:11 | [Basic Settings]
| |
16:11 | Start Nepomuk=false
| |
16:11 | if you disable akonadi (process does not run) a lot of programs could complain
| |
16:12 | they are (sigh!) increasing dependencies upon that storage backend
| |
16:12 | (not only PIM programs)
| |
16:13 | <alkisg> Ah ok let me try just nepomuk then
| |
16:15 | <markit> and change akonadi backend?
| |
16:15 | <alkisg> 22 sec to login (see the panel), 40 or so to hear the login sound, 70 mb for login
| |
16:15 | <markit> let's wait until it stabilizes...
| |
16:15 | don't want see a 200MB jump ;P
| |
16:15 | <alkisg> It did
| |
16:15 | 70 mb
| |
16:15 | Ah
| |
16:15 | <markit> GREAT!
| |
16:15 | :(
| |
16:15 | <alkisg> Wait it raises again... :P
| |
16:15 | <markit> lol
| |
16:15 | I know the beast ;P
| |
16:16 | <alkisg> 93 mb
| |
16:16 | So nepomuk saved 50mb
| |
16:16 | <markit> is 30% :)
| |
16:16 | <alkisg> I think all that is acceptable now
| |
16:16 | <markit> just find other 3 bottleneck, and will boot in 0 seconds ;P
| |
16:16 | <alkisg> You can optimize a bit more, but it should work even for multiple clients
| |
16:16 | Haha
| |
16:16 | <markit> YES, sure!!!
| |
16:17 | but what did you did to fix it?
| |
16:17 | <alkisg> OK so your basic problem was that you didn't set the environment variable from the correct place
| |
16:17 | <markit> yep, since default settings is "LTSP allergic"
| |
16:17 | <alkisg> We could fix that in ltsp though
| |
16:17 | <markit> I mean, default is to /var/tmp and this will NEVER work AFAIU
| |
16:18 | oh, that would be great
| |
16:18 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 245 seconds) | |
16:18 | <alkisg> OK let me think... you only need that for KDE fat clients, nowhere else
| |
16:19 | So it should check for the session name
| |
16:19 | <markit> mm markit started troubleshooting 30 days ago... result, nothing works fine. alkisg started troubleshooting at 16.53... result after 1 hour and some minute: problem fixed
| |
16:19 | <alkisg> Haha
| |
16:19 | <markit> don't know if I must be happy or depressed ;P
| |
16:19 | <alkisg> It depends on if you want to be a programmer or a floss advocator :D
| |
16:20 | <markit> lol, I would love to take both
| |
16:20 | and I do hope to be a better foss advocator than a sysadmin
| |
16:23 | alkisg: I've to go outside with my wife (that has been so patient so far...), could you drop me a line by email with the solution and a brief description of the problem (I've wasted so much time that I would love to see what really was wrong and why)?
| |
16:23 | <alkisg> markit: sure
| |
16:23 | Have a great time
| |
16:24 | <markit> I do thank you SOOOOO MUCH
| |
16:24 | you are great technically and so helpful and friendly
| |
16:24 | what about cloning you?
| |
16:24 | alkisg2 has joined IRC (alkisg2!59d28d19@gateway/web/freenode/ip.89.210.141.25) | |
16:24 | <alkisg2> done :P
| |
16:25 | <markit> hahahaha
| |
16:25 | do hope I will not clone myself too ;P
| |
16:25 | alkisg2 has left IRC (alkisg2!59d28d19@gateway/web/freenode/ip.89.210.141.25, Client Quit) | |
16:25 | <alkisg> Haha
| |
16:25 | <markit> see you later :)
| |
16:25 | markit has left IRC (markit!~marco@88-149-177-66.v4.ngi.it, ) | |
16:25 | <alkisg> bb
| |
16:31 | Pinguin123 has joined IRC (Pinguin123!~smuxi@biton.xs4all.nl) | |
16:32 | <alkisg> Doh no sshfs mount for /home/username, fun
| |
16:33 | Maybe it took too long to be unmounted, and then wasn't mounted again on second login...
| |
16:42 | No, stuff was left behind under /home/username locally... weird how it was created by kde before the sshfs mount...
| |
16:56 | Stopping nepomuk made that problem go away, ok
| |
17:00 | Pinguin123 has left IRC (Pinguin123!~smuxi@biton.xs4all.nl, Remote host closed the connection) | |
17:13 | andygraybeal_ has joined IRC (andygraybeal_!~andy@h82.200.130.174.dynamic.ip.windstream.net) | |
17:16 | khildin has joined IRC (khildin!~khildin@ip-83-134-214-146.dsl.scarlet.be) | |
17:29 | ltspuser_50 has joined IRC (ltspuser_50!5c2cc70e@gateway/web/freenode/ip.92.44.199.14) | |
18:16 | Parker955_Away is now known as Parker955 | |
18:25 | bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) | |
18:25 | Parker955 is now known as Parker955_Away | |
18:31 | <Hyperbyte> What a jump... wow! #stratos
| |
18:43 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 260 seconds) | |
18:58 | Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
19:14 | vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net) | |
19:14 | vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc) | |
19:16 | Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas) | |
19:47 | ricotz has left IRC (ricotz!~rico@ubuntu/member/ricotz, Quit: Ex-Chat) | |
20:04 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection) | |
20:10 | Mava has left IRC (Mava!~Mava@ip-45-201.dhcp.opintanner.fi, Remote host closed the connection) | |
20:36 | mmetzger has left IRC (mmetzger!~mmetzger@99-71-214-196.lightspeed.mdldtx.sbcglobal.net, Quit: leaving) | |
20:39 | khildin_ has joined IRC (khildin_!~khildin@ip-80-236-212-198.dsl.scarlet.be) | |
20:42 | khildin has left IRC (khildin!~khildin@ip-83-134-214-146.dsl.scarlet.be, Ping timeout: 245 seconds) | |
21:19 | FGXR6 has joined IRC (FGXR6!~phantom@ppp121-44-8-89.lns20.syd6.internode.on.net) | |
21:30 | FGXR6 has left IRC (FGXR6!~phantom@ppp121-44-8-89.lns20.syd6.internode.on.net, Read error: Operation timed out) | |
22:10 | andygraybeal_ has left IRC (andygraybeal_!~andy@h82.200.130.174.dynamic.ip.windstream.net, Ping timeout: 245 seconds) | |
22:12 | ltspuser_50 has left IRC (ltspuser_50!5c2cc70e@gateway/web/freenode/ip.92.44.199.14, Ping timeout: 245 seconds) | |
22:16 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 255 seconds) | |
22:45 | khildin_ has left IRC (khildin_!~khildin@ip-80-236-212-198.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
22:59 | Parker955_Away is now known as Parker955 | |
23:31 | shogunx has left IRC (shogunx!~shogunx@2001:4978:106:1:694c:87d6:c68a:a1de, Quit: Fnord) | |