IRC chat logs for #ltsp on irc.freenode.net (webchat)


Channel log from 7 June 2017   (all times are UTC)

00:08gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Remote host closed the connection)
00:30vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
01:10gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com)
01:43gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 268 seconds)
02:09GodFather has left IRC (GodFather!~rcc@47.33.250.142, Ping timeout: 260 seconds)
02:41gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com)
03:15gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 268 seconds)
03:58lucascastro has joined IRC (lucascastro!~lucas@186.227.186.18)
04:12gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com)
04:36johnsmith has joined IRC (johnsmith!~Adium@106.219.154.25)
04:36johnsmith has left IRC (johnsmith!~Adium@106.219.154.25)
04:44gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 246 seconds)
05:03alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 240 seconds)
05:08ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
05:08Statler has joined IRC (Statler!~Georg@p579FEEBB.dip0.t-ipconnect.de)
05:42gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com)
06:14gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 255 seconds)
06:17Eric2 has joined IRC (Eric2!~eric@sdi.iut-valence.fr)
06:21forum has joined IRC (forum!~Thunderbi@93-82-104-159.adsl.highway.telekom.at)
06:29forum has left IRC (forum!~Thunderbi@93-82-104-159.adsl.highway.telekom.at, Quit: forum)
06:32mikkel has joined IRC (mikkel!~mikkel@mail.dlvs.dk)
06:42ZAJDAN has left IRC (ZAJDAN!4d30954b@gateway/web/freenode/ip.77.48.149.75, Quit: Page closed)
06:57v4169sgr has joined IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa)
06:58
<v4169sgr>
Hello! Has anyone ever heard of Evolution (the mail client) segfaulting in thin clients, but running fine on the server?
06:58
Alternatively, is it possible to configure evolution to run fat while everything else runs thin ?
07:02alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
07:04
<alkisg>
v4169sgr: you're using ubuntu-mate with evolution instead of thunderbird? how so?
07:04
You can run some applications in "fat mode" with ltsp "remote apps", see the lts.conf man page
07:04
!lts.conf
07:04
<ltsp>
lts.conf: (#1) http://manpages.ubuntu.com/lts.conf, or (#2) lts.conf manpage is available in the ltsp-docs package
07:05
<v4169sgr>
Thank you! I'll check that out right away! :)
07:05
Yes, our users run Evolution by preference for migration reasons (look and feel)
07:06
The install is vanilla 16.04 with ubuntu-mate-desktop installed over the top and used as an option
07:06
<alkisg>
You already have a messy setup :D
07:07gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com)
07:07
<alkisg>
The 'vanilla' ubuntu is using unity, which is not developed anymore, so it's not a good option
07:08
<v4169sgr>
We prefer unity when we can run it. Mate is good for the thin clients.
07:09
I am personally agnostic, but I am going with user adoption (and hard work already invested! :)) here
07:10
<alkisg>
As a sysadmin, I always notify my users when they use something that is not developed anymore
07:10
<v4169sgr>
good policy :)
07:10
<alkisg>
They don't know that it's no longer maintained. I do. So I tell them to avoid it. :)
07:10
<v4169sgr>
think of it as a 'soft migration' :P
07:10
<alkisg>
np
07:11gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 255 seconds)
07:12
<alkisg>
Btw, your clients have 1 GB RAM, so they should probably be used as fat clients and not as thin clients
07:12
<v4169sgr>
yes, true, and I've tested fat vs thin, but found thin to be much more responsive, so will stick with thin
07:12
1 GB really isn't enough even for mate
07:12
<alkisg>
Even if they only have N270 CPU, with... 270 passmark (wow, what a coincidence...)
07:13
It depends on your network and server too. If your server has more than 1 GB *per client*, then OK
07:13
E.g. for 20 clients => 20 GB RAM on the server...
07:13
<v4169sgr>
pardon my ignorance but isn't lts.conf REMOTE_APPS intended for fat client set ups wanting to run an app on the server?
07:13
I have the opposite case: I run thin but want to try runnjing evolution locally
07:13
<alkisg>
Ah sorry you are right,
07:14
you're looking for LTSP_LOCALAPPS instead
07:14
<v4169sgr>
thanks, will search instead for that
07:14
and yes my server is more than adequately provisioned (16 GB, 3 clients)
07:14
<alkisg>
LOCAL APPLICATIONS LOCAL_APPS boolean, default True
07:15
LOCAL_APPS=True in lts.conf, and also the menu items there
07:15
<v4169sgr>
and I am sitting on a 1 gbps LAN :)
07:15
<alkisg>
It should be OK then, except for full screen videos etc
07:15
<v4169sgr>
full screen videos run ok too
07:15
very acceptable
07:15
<alkisg>
A full screen video needs 2.5 gbps per client
07:15
<v4169sgr>
yes thats ok too
07:16
<alkisg>
So for 3 clients you'd need 7.5 gbps, and you only have 1 gbps :)
07:16
So you have some dropped frames, but it should be fine
07:16
<v4169sgr>
from experience 1 gbps can carry the load
07:16
without dropped frames
07:16
<alkisg>
Nah
07:16
Math beats experience any time
07:17
!thin-client-bandwidth
07:17
<ltsp>
I do not know about 'thin-client-bandwidth', but I do know about these similar topics: 'thin-clients-bandwidth'
07:17
<v4169sgr>
LOL :P
07:17
<alkisg>
!thin-clients-bandwidth
07:17
<ltsp>
thin-clients-bandwidth: A small explanation why thin clients can't perform well with video, lots of screen updates etc: https://sourceforge.net/p/ltsp/mailman/message/35694699/
07:17
<v4169sgr>
understood, and this is something large scale installations need to watch for
07:17
but my installation is very small
07:18
<alkisg>
As I said, you have dropped frames. If it's ok with you, it's ok. But I can't accept that you don't have dropped frames :)
07:18
Math says otherwise
07:20
<v4169sgr>
Would I use "LOCAL_APPS_WHITELIST = evolution" to specify only evolution to run locally?
07:21
<alkisg>
You only need LOCAL_APPS, LOCAL_APPS_MENU, and LOCAL_APPS_MENU_ITEMS
07:21
You don't need the whitelist
07:22
<v4169sgr>
Thanks. Do you have an example of usage? I only want to run evolution locally, nothing else
07:23
<alkisg>
LOCAL_APPS=True, LOCAL_APPS_MENU=True, LOCAL_APPS_MENU_ITEMS=evolution
07:23
<v4169sgr>
Thank you, will edit and test
07:24
and thanks for your instant and knowledgeable help !!! :)
07:24
<alkisg>
np
07:33ZAJDAN has joined IRC (ZAJDAN!4d30954b@gateway/web/freenode/ip.77.48.149.75)
07:34
<ZAJDAN>
LTSP pnp for Debian9 ..exist any howto?
07:42
<v4169sgr>
ZAJDAN: I found this very useful
07:43
https://wiki.debian.org/LTSP/Howto
07:43
The PNP section is the second part of the page
07:43
@alkisg: setting evolution as a local app did not work: it still segfaults
07:44
<alkisg>
v4169sgr: rarely, applications have issues with sshfs
07:44
Evolution might be one such application; although I assume someone would have mentioned it...
07:44
Try on the server, to mount sshfs home and launch evolution there
07:45
So that ltsp isn't involved at all
07:45
If evolution fails on sshfs, then there are ways around the issue
07:45
<v4169sgr>
ok, dumb question time, what is sshfs and where can I find it?
07:46
<alkisg>
sshfs is the remote file system that ltsp uses by default
07:47
You can see its man page here: manpages.ubuntu.com/sshfs
07:47
Eh, wait, you also said evolution breaks on thin clients too
07:47
Sorry I'm not very focused today
07:47
Thin client session runs on the server
07:47
So there's no sshfs there
07:47
Scratch that idea out
07:47
<ZAJDAN>
v4169sgr: yes, but from there is not clear what packages I should install....the section 'Installing LTSP using the LTSP-PNP method' speaks about setting not installation
07:48
<alkisg>
v4169sgr: try putting this line in lts.conf: X_SMART_COLOR_DEPTH=False. Then reboot the thin clients, to see if it has an issue with the color depth.
07:48
<v4169sgr>
@ZANJAN: Install ltsp-server-standalone, ltsp-client (since there is to be no separate chroot) dnsmasq (an easy to configure tool) other desired software and the desktop environment of your choice.
07:48
from the page
07:49
item #2, second list
07:49
Thanks alkisg :) Will try ...
07:49forum has joined IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at)
07:51Statler has left IRC (Statler!~Georg@p579FEEBB.dip0.t-ipconnect.de, Remote host closed the connection)
07:51
<ZAJDAN>
v4169sgr: ok..I will try to record all steps to create some simple manual
07:51johnsmith_ has joined IRC (johnsmith_!6adb0364@gateway/web/freenode/ip.106.219.3.100)
07:56
<v4169sgr>
By the way I am finding that sometimes after reboots the dnsmasq service needs to be restarted, else the client fails to find the TFTP service
07:56
I've added "sudo service dnsmasq restart" to rc.local but that doesn't seem to be helping
07:56
I still need to manually restart
07:57
so wonder if I can run this line after some small delay
07:57
<alkisg>
v4169sgr: what's the output of this? egrep -rv '^$|^#' /etc/dnsmasq.* | nc termbin.com 9999
07:57
<v4169sgr>
http://termbin.com/byzq
07:58
no idea what that means :)
07:58
<alkisg>
The problem is "bind-interfaces", you didn't remove it
07:58
!ltsp-pnp
07:58
<ltsp>
ltsp-pnp: ltsp-pnp is an alternative (upstream) method to maintain LTSP installations for thin and fat clients that doesn't involve chroots: https://help.ubuntu.com/community/UbuntuLTSP/ltsp-pnp
07:58
<alkisg>
Hrm, I need to document that bug in network-manager too
07:59
<v4169sgr>
thanks, so what do I need to do?
07:59
<alkisg>
Remove the line "bind-interfaces" from the file "/etc/dnsmasq.d/network-manager"
08:01
<v4169sgr>
# WARNING: changes to this file will get lost if network-manager is removed.
08:01
Does this mean changes are not persistent over time ?
08:02
<alkisg>
No
08:02
They're persistent
08:02
<v4169sgr>
ok, backed up original and changed, will reboot and try
08:02
and try the other lts.conf change too :)
08:02
<alkisg>
I hope you didn't back it up in the same dir
08:02
Because then it would still cause issues :)
08:03
<v4169sgr>
So a filename of "network-manager.07Jun2017" isn't safe?
08:03
if so that would be a first for me
08:04
<alkisg>
Yes, it's not safe
08:04
Because dnsmasq still reads that file
08:04
So the bad option still applies
08:04
<v4169sgr>
can I create a "backups" directory immediately underneath?
08:04
<alkisg>
This is an issue with all config.d dirs
08:04
<v4169sgr>
I need to safeguard the original
08:04
<alkisg>
Create a backup somewhere else, e.g. in /home/user/mybackups
08:06
<v4169sgr>
saved here
08:06
~/systembackups/etc/dnsmasq.d/network-manager.07Jun2017
08:06
being me I've gone totally over the top LOL
08:08v4169sgr has left IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa)
08:10v4169sgr has joined IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa)
08:16
<v4169sgr>
@alkisg: ok, removing the bind-interfaces directive seems to have worked
08:16
<alkisg>
Yes I reported that bug ages ago but some Ubuntu maintainers just won't listen :/
08:17
Fortunately they'll stop abusing dnsmasq in 17.10
08:17
<v4169sgr>
Setting X_SMART_COLOR_DEPTH=False unfortunately did not prevent evolution segfaulting
08:17
Thanks and well done for persisting with it :)
08:18
<alkisg>
So, you're saying that evolution works for userA on the server, but not for the same userA on a thin client?
08:19
<v4169sgr>
correct
08:19
and that is also independent of using mate or unity as a dE
08:20
so LTSP seems to be the common factor
08:21Statler has joined IRC (Statler!~Georg@mail.lohn24.de)
08:21
<v4169sgr>
unfortunately there just doesn't seem to be a lot on this out there
08:25
How about setting SSH_FOLLOW_SYMLINKS to True ?
08:25
<alkisg>
Before using LOCAL_APPS=True, you were running evolution on the server (via the thin client session)
08:26
<v4169sgr>
presume that's only for local apps
08:26
<alkisg>
So sshfs was not involved at all there
08:26
<v4169sgr>
ye4s
08:26
yes
08:26
correct
08:26
<alkisg>
So if it's not sshfs and it's not the color depth... I'm not sure why it would be ltsp-related
08:26
<v4169sgr>
ok, so nothing obvious to me in the lts conf man page then
08:27
<alkisg>
And if it doesn't even run locally (localapps) then it's not related to "remote xorg" either
08:27
<v4169sgr>
I could try "gdb evolution" on the client and see if I can get any more information that way
08:28
<alkisg>
So, the problem doesn't really sound like it's related to ltsp... so I'm not fond of spending too much time with it ;)
08:28ZAJDAN has left IRC (ZAJDAN!4d30954b@gateway/web/freenode/ip.77.48.149.75, Ping timeout: 260 seconds)
08:29
<v4169sgr>
well it's only a pb on the client, so not sure what else it could be :)
08:29
agreed it is hard to diagnose tho
08:30
<alkisg>
Ah, another thing that might be related, is the login manager, ldm, along with the accountsservice
08:30Eric2 has left IRC (Eric2!~eric@sdi.iut-valence.fr, Ping timeout: 246 seconds)
08:30
<alkisg>
E.g. evolution might be querying them about the logged in users etc
08:30
Anyways... yeah sounds tricky to diagnose
08:34
<v4169sgr>
This is the result
08:34
Thread 1 "evolution" received signal SIGSEGV, Segmentation fault.
08:34
0xb7fe3d9b in check_match (undef_name=undef_name@entry=0xb3308ad1 "mincore",
08:34
ref=ref@entry=0x0, version=version@entry=0x0, flags=7, type_class=0,
08:34
sym=0xb32f91cc, symidx=163, strtab=0xb32f96cc "", map=0xb330a000,
08:34
versioned_sym=0xbf8000ac, num_versions=0xbf8000a8) at dl-lookup.c:110
08:34
110 dl-lookup.c: No such file or directory.
08:34
At first sight I'd say that's internal to the app, but not sure
08:36
running the same command on the server does not produce anything like this: just normal running
08:42
https://ubuntuforums.org/showthread.php?t=2363142
08:43
<alkisg>
I don't think any ltsp developer is participating in ubuntuforums...
08:43
We're mostly using IRC, or the mailing lists
08:44
You could ask in the mailing lists if anyone else has that issue, or if it just affects you
08:46
<v4169sgr>
yes indeed, digging deeper seems that something similar was reported in the past few months on a centos install
08:46
but no action taken
08:47
seems possibly connected with stack management or memory allocation
08:48Eric2 has joined IRC (Eric2!~eric@sdi.iut-valence.fr)
08:50
<bcg_>
probably not related, but we just noticed random segfaults on localapps firefox if running in 32bit kernel/chroot. quick fix was to recreate chroot as 64bit.
08:53johnsmith_ has left IRC (johnsmith_!6adb0364@gateway/web/freenode/ip.106.219.3.100, Ping timeout: 260 seconds)
09:22
<v4169sgr>
Thanks bcg_ :) Not an option for me I am afraid as the clients must run 32 bit. H/W is DELL FX 170
09:22
<alkisg>
The server is 32 bit and runs evolution, so that shouldn't be related in this case
09:23
<v4169sgr>
agreed
09:42bcg_ is now known as bcg
09:46
<v4169sgr>
Seriously considering migrating from evolution to thunderbird
09:46ogra has left IRC (ogra!~ogra_@ubuntu/member/ogra, Quit: Coyote finally caught me)
09:47
<v4169sgr>
I already use thunderbird for another mail account, so migration would not be so straightforward for me, but would be simpler for other users
09:47
apart from the 10+ years of emails to save in mboxes LOL
09:47
<alkisg>
Thunderbird supports multiple accounts
09:48ogra_ has joined IRC (ogra_!~ogra_@p5098ed03.dip0.t-ipconnect.de)
09:50
<v4169sgr>
considering merits of a hard cut over and not migrate the mboxes, but leave them as archive reference, and simply set up the accounts on thunderbird
10:12markus_e92 has left IRC (markus_e92!~markus_e9@80-121-121-35.adsl.highway.telekom.at, Ping timeout: 255 seconds)
10:14markus_e92 has joined IRC (markus_e92!~markus_e9@62-46-102-74.adsl.highway.telekom.at)
10:19ogra_ is now known as ogra
10:20ogra has joined IRC (ogra!~ogra_@ubuntu/member/ogra)
10:24zerkalo has joined IRC (zerkalo!myricae@ny1.hashbang.sh)
10:25
<v4169sgr>
incidentally, does anyone know what this means:
10:25
cat /sys/block/sda/queue/scheduler
10:25
noop [deadline] cfq
10:26
Does this mean I am using the deadline scheduler?
10:26
important for me as my server runs with an SSD on /dev/sda
10:37forum has left IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at, Ping timeout: 240 seconds)
10:39forum has joined IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at)
10:58v4169sgr has left IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa, Ping timeout: 240 seconds)
10:59v4169sgr has joined IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa)
11:00
<alkisg>
How is the cpu scheduler related to the disk?!
11:00
Whooops sorry, misread
11:04TatankaT has joined IRC (TatankaT!~tim@193.190.253.114)
11:06
<bcg>
v4169sgr: that means you're using deadline.
11:07
deadline is fine for ssd too.
11:07
so is cfq.
11:08
see: https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.9-IO-Scheduler-SSD
11:09
alkisg: I just found a bug in ltsp-update-kernels. on rhel it might select older kernel because of sort. for example:
11:09
-rwxr-xr-x. 1 root root 4137728 May 30 19:45 vmlinuz-2.6.32-696.3.1.el6.i686
11:09
-rwxr-xr-x. 1 root root 4137504 Mar 22 00:34 vmlinuz-2.6.32-696.el6.i686
11:10
.3.1.el6 is newer but .el6 sorts as last.
11:10
I'll have to replace "find | sort" with "ls --sort=time" to fix this.
11:11forum has left IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at, Read error: Connection reset by peer)
11:13forum has joined IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at)
11:14
<v4169sgr>
Thanks bcg :)
11:14ZAJDAN has joined IRC (ZAJDAN!4d30954b@gateway/web/freenode/ip.77.48.149.75)
11:16
<ZAJDAN>
I started to prepare LTSP on pure fresh installation of Debian 9, but first problem which appears during installation dnsmasq: Failed to start dnsmasq -A lighwei...
11:21
do anybody has experience?
11:22Eric2 has left IRC (Eric2!~eric@sdi.iut-valence.fr, Ping timeout: 245 seconds)
11:23
<alkisg>
bcg: sort=time doesn't sound good, e.g. if I touch a kernel it'll be newer?
11:24
<bcg>
any better idea?
11:24
<alkisg>
You can define a custom sort function, but depending on file date doesn't sound good
11:24ZAJDAN has left IRC (ZAJDAN!4d30954b@gateway/web/freenode/ip.77.48.149.75, Quit: Page closed)
11:24
<bcg>
is there "version number" sort? I remember seeing one, somewhere.
11:24
<alkisg>
sort -g
11:25
sort -v something
11:25
We already use that, afaik
11:25ZAJDAN has joined IRC (ZAJDAN!4d30954b@gateway/web/freenode/ip.77.48.149.75)
11:25
<bcg>
ah.yes.
11:25
find "$tftpname" -mindepth 1 -maxdepth 1 -type f -printf "%f\n" \
11:25
| sed -n "$KERNEL_NAMES" | sort -k 4,4V -k 3,3rV \
11:25
nope.
11:26
i'll fix that in my ltsp-rhel
11:27
hmm... or is it that V after 4... Anyway, I end up with wrong kernel. I'll debug.
12:02
problem seems to be in server/ltsp-build-client file, detect_latest_kernel() function. it has:
12:02
kernelversion="`ls -d $ROOT/lib/modules/2* | sort -nr | head -n1 | xargs basename`"
12:04
<alkisg>
If there's old rhel-specific code around, try to check the generic or the debian/ubuntu code for it instead
12:04Faith has joined IRC (Faith!~paty_@unaffiliated/faith)
12:04
<bcg>
apparently.
12:04
<alkisg>
We fixed many things when there was no rhel maintainer around...
12:04
<bcg>
generic code seems better.
12:04
<alkisg>
E.g. I don't think we check for 2* anywhere, to detect the kernel version
12:05
<bcg>
I'll just have to fix KERNEL_NAMES define for rhel.
12:06
rhel-code creates vmlinuz.ltsp and initrd.ltsp symlinks. does generic code create vmlinuz.x86_64?
12:08
<alkisg>
Ideally we want "vmlinuz" and "initrd" symlinks for all distros
12:08
Then we can have a generic pxelinux.cfg/default for all of them
12:10
<bcg>
is it named just "vmlinuz", no dot-something?
12:10
I don't have any reference ubuntu-ltsp around...
12:28
<alkisg>
We generate vmlinuz and initrd.img with no dots
12:29
And we also generate vmlinuz-generic or vmlinuz-generic-pae etc, for different kernel flavors (not versions but flavors), but those don't matter much
13:19v4169sgr has left IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa)
13:21v4169sgr has joined IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa)
13:32
<ZAJDAN>
on Debian 9 is ltsp.conf on another place as is usual?
13:33
because in /var/lib/tftpboot/ltsp/i386/ ...is not
13:36forum has left IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at, Ping timeout: 246 seconds)
13:38forum has joined IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at)
13:38ben_nabiy has joined IRC (ben_nabiy!~bennabiy@unaffiliated/bennabiy)
13:44
<ZAJDAN>
ahhhh..I forgot, that I have to create the config
13:45cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 255 seconds)
13:47cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
13:49
<v4169sgr>
@ZANJAN, one would need to use "ltsp-config lts.conf"
13:55
<ZAJDAN>
v4169sgr.....thnx yes..already created
14:00
Debian 9 - Epoptes -> thinClient reboot doesnt works (frozen with SQUASHFS error: Unable to read page)
14:11
erka
14:18mikkel has left IRC (mikkel!~mikkel@mail.dlvs.dk, Quit: Leaving)
14:22professor^profes has joined IRC (professor^profes!b104a921@gateway/web/freenode/ip.177.4.169.33)
14:22
<professor^profes>
Bom dia
14:26
<v4169sgr>
trying to clean my system:
14:26
Jun 7 15:24:43 aammscott com.canonical.Unity.Scope.Applications[4006]: (unity-scope-loader:5824): unity-applications-daemon-WARNING **: daemon.vala:1111: Error performing search '': Timeout was reached
14:26
would suggest disabling global file indexing should be up there in top 10 things to do in fresh installs of 16.04
14:27
iowait still 25%
14:52sutula has left IRC (sutula!~sutula@207-118-157-250.dyn.centurytel.net, Ping timeout: 255 seconds)
14:58sutula has joined IRC (sutula!~sutula@207-118-149-86.dyn.centurytel.net)
15:03professor^profes has left IRC (professor^profes!b104a921@gateway/web/freenode/ip.177.4.169.33, Quit: Page closed)
15:40Statler has left IRC (Statler!~Georg@mail.lohn24.de, Remote host closed the connection)
15:40vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
15:46lucascastro has left IRC (lucascastro!~lucas@186.227.186.18, Remote host closed the connection)
15:46lucascastro has joined IRC (lucascastro!~lucas@186.227.186.18)
15:52forum has left IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at, Ping timeout: 240 seconds)
15:58forum has joined IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at)
16:30Eric2 has joined IRC (Eric2!~eric@sdi.iut-valence.fr)
17:03forum has left IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at, Remote host closed the connection)
17:08forum has joined IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at)
17:13forum has left IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at, Remote host closed the connection)
17:16forum has joined IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at)
17:26forum has left IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at, Remote host closed the connection)
17:28forum has joined IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at)
17:57forum has left IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at, Remote host closed the connection)
17:57forum has joined IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at)
18:11Eric2 has left IRC (Eric2!~eric@sdi.iut-valence.fr, Ping timeout: 246 seconds)
18:34ben_nabiy has left IRC (ben_nabiy!~bennabiy@unaffiliated/bennabiy, Remote host closed the connection)
18:34bennabiy has left IRC (bennabiy!~bennabiy@unaffiliated/bennabiy, Remote host closed the connection)
18:35bennabiy has joined IRC (bennabiy!~bennabiy@unaffiliated/bennabiy)
18:45
<quinox>
that file indexer of KDE is annoying -_-
18:45
I had some serious problems getting it to stop spawning
18:49
<v4169sgr>
you mean beagle? yes the ditro maintainers seem to like that kind of thing. the one behind the dash indexing seems dreadful. luckily it can be turned off in system settings
18:51
<quinox>
mm I think I had trouble with Baloo
18:52
it seems Beagle was their old indexer
18:52
it was probably in their list of requirements they had to implement for the new one:
18:53
"Baloo must suck at least as bad as Beagle at thrashing your harddrive"
18:57
I use Awesome myself
18:57
it starts up in like 0.3 seconds
18:58
those other users that use KDE have to actually wait for their desktop to load
18:58
they even have to be amused with an animated loader to make it bearable
18:59
<v4169sgr>
imagine what that would do to an ssd ... :P
19:20forum has left IRC (forum!~Thunderbi@212-197-181-226.adsl.highway.telekom.at, Quit: forum)
19:23
<alkisg>
Maybe they should have named it Mowgli, he was definately lighter than baloo
19:41
<||cw>
indexing is mostly read right? an ssd would make quick work of it
20:48Faith has left IRC (Faith!~paty_@unaffiliated/faith, Quit: Leaving)
20:55lucascastro has left IRC (lucascastro!~lucas@186.227.186.18, Remote host closed the connection)
20:56gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com)
20:59v4169sgr has left IRC (v4169sgr!~andrew@235.204.187.81.in-addr.arpa)
21:26tek__ has joined IRC (tek__!tek@kapsi.fi)
21:26sebd_ has joined IRC (sebd_!~seb@aditu.ldd.fr)
21:29tek_ has left IRC (tek_!tek@kapsi.fi, Ping timeout: 240 seconds)
21:29sebd has left IRC (sebd!~seb@aditu.ldd.fr, Ping timeout: 240 seconds)
21:29pppingme has left IRC (pppingme!~pppingme@unaffiliated/pppingme, Ping timeout: 240 seconds)
21:32pppingme has joined IRC (pppingme!~pppingme@unaffiliated/pppingme)
21:33markus_e92 has left IRC (markus_e92!~markus_e9@62-46-102-74.adsl.highway.telekom.at, Ping timeout: 240 seconds)
21:34markus_e92 has joined IRC (markus_e92!~markus_e9@62-46-102-74.adsl.highway.telekom.at)
21:41ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
21:45gehidore has left IRC (gehidore!~username@unaffiliated/man, Ping timeout: 268 seconds)
21:48gehidore has joined IRC (gehidore!~username@unaffiliated/man)
22:46GodFather has joined IRC (GodFather!~rcc@2600:1007:b009:c40f:a536:ff49:82f0:9f21)
23:43gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Remote host closed the connection)
23:43gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com)
23:48gbaman has left IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com, Ping timeout: 240 seconds)
23:54gbaman has joined IRC (gbaman!~gbaman@host81-142-46-233.in-addr.btopenworld.com)