IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 28 March 2012 (all times are UTC)
| 00:03 | shogunx has left IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com, Read error: No route to host) | |
| 00:04 | shogunx has joined IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com) | |
| 00:11 | rthomson has left IRC (rthomson!~rthomson@mars.pet.ubc.ca, Quit: Reached EOD) | |
| 00:15 | adrianorg has joined IRC (adrianorg!~adrianorg@177.18.170.194) | |
| 01:41 | alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Quit: Хана X'ам !!!) | |
| 01:56 | Parker955 is now known as Parker955_Away | |
| 01:57 | Parker955_Away is now known as Parker955 | |
| 02:06 | irule has joined IRC (irule!~irule@189.199.30.249) | |
| 02:24 | adrianorg has left IRC (adrianorg!~adrianorg@177.18.170.194, Ping timeout: 240 seconds) | |
| 03:20 | Parker955 is now known as Parker955_Away | |
| 03:26 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 03:40 | kodez has joined IRC (kodez!~kodez@8ta-151-6-32.telkomadsl.co.za) | |
| 03:46 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 245 seconds) | |
| 04:25 | irule has left IRC (irule!~irule@189.199.30.249, Read error: No route to host) | |
| 04:46 | staffencasa has left IRC (staffencasa!~staffenca@128-193-148-207.oregonstate.edu, Ping timeout: 240 seconds) | |
| 04:47 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 252 seconds) | |
| 04:56 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 05:00 | Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71) | |
| 05:05 | <alkisg> knipwim: around?
| |
| 05:09 | <knipwim> for a bit
| |
| 05:09 | was just checking how late i have to be on the train
| |
| 05:10 | <alkisg> knipwim: I'm going to split ltsp-info as we proposed
| |
| 05:10 | I.e. separate debian/gentoo functions, a Gentoo-functions.d/ltsp-info, and a separate ltsp-info-opensuse
| |
| 05:11 | Since opensuse doesn't follow the ltsp-info main code
| |
| 05:11 | OK?
| |
| 05:11 | That way we'll have common code
| |
| 05:11 | I'll need to put an empty chroot_release() function in your Gentoo-functions.d/ltsp-info script
| |
| 05:12 | That's what I wanted to ask you about ^, so that the main code is completely common
| |
| 05:13 | <knipwim> what does chroot_release do?
| |
| 05:14 | <alkisg> Debian_chroot_release() {
| |
| 05:14 | if [ -x $chroot/usr/bin/lsb_release ]; then
| |
| 05:14 | echo "chroot information: $chroot"
| |
| 05:14 | ROOT=$chroot ltsp-chroot lsb_release --all
| |
| 05:14 | echo
| |
| 05:14 | fi
| |
| 05:14 | }
| |
| 05:14 | If you want you can implement the empty function after my commit...
| |
| 05:15 | <knipwim> cool you're just going ahead with the plan
| |
| 05:15 | <alkisg> Yes, I think we gave enough time for disagreements :)
| |
| 05:15 | And having common code is a big plus, so I'd like to go on with it
| |
| 05:15 | <knipwim> exactly
| |
| 05:16 | <alkisg> OK, ty, have a nice day :)
| |
| 05:16 | <knipwim> you too
| |
| 05:16 | btw, i was thinking
| |
| 05:17 | does epoptes also display some server statistics?
| |
| 05:17 | <alkisg> No, just client statistics
| |
| 05:17 | But the code works on the server too, we just don't have a gui that displays it
| |
| 05:17 | <knipwim> more a teacher tool than an administrator tool
| |
| 05:18 | <alkisg> Yes
| |
| 05:18 | It doesn't require root to run
| |
| 05:24 | knipwim: btw you have an unused Gentoo_packages() function in ltsp-info
| |
| 05:26 | <knipwim> currently? or after your commit?
| |
| 05:27 | <alkisg> knipwim: currently
| |
| 05:27 | Anyway I'll commit what I can, and you can fix the result later
| |
| 05:28 | <knipwim> it's called by Gentoo_server_packages
| |
| 05:28 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 05:28 | <alkisg> Ah sorry I has halfway moving stuff and I didn't see it
| |
| 05:28 | <knipwim> but indeed
| |
| 05:28 | <alkisg> OK, so you only need that in your ltsp-info-functions, no problem
| |
| 05:29 | <knipwim> i'll look at your commit
| |
| 05:29 | <alkisg> cyberorg: I'm extracting your ltsp-info code into a separate file, how do you want me to call it? ltsp-info-SUSE_LINUX? You can rename that to ltsp-info at the packaging stage
| |
| 05:30 | (Good morning btw :))
| |
| 05:38 | bauerski has joined IRC (bauerski!~witekb@frodo.psp.opole.pl) | |
| 05:40 | <alkisg> cyberorg: I named it ltsp-info-SUSE_LINUX, please rename it if that name isn't good enough, r2154
| |
| 05:45 | <knipwim> alkisg: do i have to package server/functions.d/Gentoo/ltsp-info-functions as /usr/share/ltsp/ltsp-server-functions ?
| |
| 05:46 | <alkisg> knipwim: no, as /usr/share/ltsp/ltsp-info-functions
| |
| 05:46 | So don't do it on a per-file basis, copy the whole dir
| |
| 05:46 | So in the future e.g. ltsp-update-image-functions gets copied as well
| |
| 05:47 | <knipwim> but /usr/share/ltsp/ltsp-info-functions doesn't get sourced
| |
| 05:47 | <alkisg> It does, from ltsp-server-functions
| |
| 05:47 | # Source tool-specific functions, if they're provided.
| |
| 05:47 | # Recursive inclusions shouldn't ever happen, but let's prevent them anyway.
| |
| 05:47 | if [ -z "$ltsp_tool" ]; then
| |
| 05:47 | ltsp_tool=${0##*/}
| |
| 05:47 | if [ -f "/usr/share/ltsp/$ltsp_tool-functions" ]; then
| |
| 05:47 | . "/usr/share/ltsp/$ltsp_tool-functions"
| |
| 05:47 | fi
| |
| 05:47 | fi
| |
| 05:48 | It works for any tool, ltsp-info, ltsp-update-image etc
| |
| 05:48 | <knipwim> check
| |
| 05:48 | nice :)
| |
| 05:49 | <alkisg> ltsp-info now looks much simpler, at least :)
| |
| 05:49 | <knipwim> moreover, this architecture is much more extensible and consistant
| |
| 05:49 | <alkisg> We just need functions on every case were we use VENDOR
| |
| 05:50 | <knipwim> but check you later, have to catch the train
| |
| 05:50 | <alkisg> bb
| |
| 06:04 | shawnp0wers has left IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers, Ping timeout: 248 seconds) | |
| 06:05 | shawnp0wers has joined IRC (shawnp0wers!~spowers@71-13-74-18.static.aldl.mi.charter.com) | |
| 06:05 | shawnp0wers has joined IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers) | |
| 06:08 | cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 260 seconds) | |
| 06:12 | shawnp0wers has left IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers, Ping timeout: 265 seconds) | |
| 06:21 | shawnp0wers has joined IRC (shawnp0wers!~spowers@71-13-74-18.static.aldl.mi.charter.com) | |
| 06:21 | shawnp0wers has joined IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers) | |
| 06:51 | shawnp0wers has left IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers, Ping timeout: 260 seconds) | |
| 06:53 | shawnp0wers has joined IRC (shawnp0wers!~spowers@71-13-74-18.static.aldl.mi.charter.com) | |
| 06:53 | shawnp0wers has joined IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers) | |
| 07:10 | DIoX|DaZ has left IRC (DIoX|DaZ!~KaKa@server.civicclub.lt, Ping timeout: 265 seconds) | |
| 07:10 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 07:11 | DIoX|DaZ has joined IRC (DIoX|DaZ!~KaKa@server.civicclub.lt) | |
| 07:22 | SmallR2002 has left IRC (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net, Ping timeout: 276 seconds) | |
| 07:24 | DIoX|DaZ has left IRC (DIoX|DaZ!~KaKa@server.civicclub.lt, Ping timeout: 260 seconds) | |
| 07:26 | DIoX|DaZ has joined IRC (DIoX|DaZ!~KaKa@server.civicclub.lt) | |
| 07:54 | dobber has joined IRC (dobber!~dobber@213.169.45.222) | |
| 07:59 | ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Excess Flood) | |
| 08:00 | ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de) | |
| 08:11 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 08:11 | cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg) | |
| 08:20 | bobby_C has joined IRC (bobby_C!~bobby@chello080108221029.1.13.vie.surfer.at) | |
| 08:37 | sep has left IRC (sep!~sep@40.211.jostedal.no, Ping timeout: 260 seconds) | |
| 08:45 | ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Excess Flood) | |
| 08:47 | ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de) | |
| 09:13 | kodez has left IRC (kodez!~kodez@8ta-151-6-32.telkomadsl.co.za, Ping timeout: 240 seconds) | |
| 09:46 | Gremble has joined IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com) | |
| 10:05 | risca has left IRC (risca!~risca@wi-secure-2252.cc.umanitoba.ca, Ping timeout: 260 seconds) | |
| 10:09 | risca has joined IRC (risca!~risca@wi-secure-2252.cc.umanitoba.ca) | |
| 10:28 | toscalix has joined IRC (toscalix!~toscalix@68.166.219.87.dynamic.jazztel.es) | |
| 10:37 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 11:06 | shogunx has left IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com, Remote host closed the connection) | |
| 11:10 | shogunx has joined IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com) | |
| 11:11 | shogunx has left IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com, Client Quit) | |
| 11:11 | shogunx has joined IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com) | |
| 11:12 | shogunx has joined IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com) | |
| 11:14 | slinky_ has joined IRC (slinky_!~slinky@91.83.208.10) | |
| 11:14 | <slinky_> hi all
| |
| 11:14 | slinky_ is now known as slin | |
| 11:14 | slin has joined IRC (slin!~slinky@frugalware/developer/slin) | |
| 11:17 | adrianorg has joined IRC (adrianorg!~adrianorg@187.113.250.182) | |
| 11:32 | <andygraybeal> in general, how is the new 12.04 for LTSP clients? i'm looking forward to it. I'm running 10.04 right now.
| |
| 11:35 | <slin> :)
| |
| 11:35 | do not
| |
| 11:35 | 11.10 is fine
| |
| 11:35 | <Hyperbyte> slin, why not?
| |
| 11:35 | <andygraybeal> ah i only want to run LTS versions
| |
| 11:35 | <slin> 12.4 is almost, but if i add keyboard layout remote then the X11 session crashes
| |
| 11:36 | while setxkbmap is ok from the client side
| |
| 11:36 | so the applet is shitty in some way
| |
| 11:36 | <Hyperbyte> slin, I'd imagine these are bugs that will be fixed, even before release?
| |
| 11:36 | <slin> Hyperbyte: for local session it's ok
| |
| 11:37 | but in front of the thinclient it crashing the client's X11 session
| |
| 11:37 | <ogra_> as long as you filed proper bugs that should get fixed before release ...
| |
| 11:37 | 12.04 is still only beta
| |
| 11:38 | <slin> hmm. true, let me fire a bug about this
| |
| 11:38 | where i should ,the ubuntu or the ltsp site?
| |
| 11:38 | khildin has joined IRC (khildin!~khildin@ip-83-134-214-50.dsl.scarlet.be) | |
| 11:38 | <ogra_> if you only see it in ubuntu, file it for ubuntu
| |
| 11:39 | if you can find other users of other distros to reproduce it, file it upstream
| |
| 11:39 | <slin> i have only ubuntu :)
| |
| 11:39 | for 60 users, with 2 of HP ML360G5 , 16G RAM and 2x4 core each
| |
| 11:39 | s/ML/DL/
| |
| 11:45 | bobby_C has left IRC (bobby_C!~bobby@chello080108221029.1.13.vie.surfer.at, Ping timeout: 245 seconds) | |
| 11:45 | <Hyperbyte> slin, apart from your bug, how's 12.04 in general with LTSP?
| |
| 11:48 | <slin> based on my user's feedback it's ok, only by this issue i had to revert temporary to 11.10
| |
| 11:48 | Gremble has left IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com, Quit: I Leave) | |
| 11:49 | <slin> my users favorizing the classic gnome interface so i can give picture only from that, but it's not a problem
| |
| 11:49 | everything is fine.
| |
| 11:49 | few gdm/gconf issues, what can be resolved by a new gnome settings profile as a quickfix
| |
| 11:51 | mandatory gconf settings are ignored, like desktop background but might be this is an upstream issue, due i moving this gconf settings since mid of 2009, inherited from an opensuse
| |
| 11:51 | the usual problem is still exist with ldap credientals and gnome-screensaver, on specific ldap configurations
| |
| 11:52 | but nothing more
| |
| 11:52 | usable in the current state as well, if not needed to change keyboard layouts :)
| |
| 11:52 | we are international compani in 40 countries so we need :D
| |
| 11:52 | risca has left IRC (risca!~risca@wi-secure-2252.cc.umanitoba.ca, Quit: Lämnar) | |
| 11:54 | <Hyperbyte> And all those locations are powered by LTSP?
| |
| 11:57 | alexqwesa has joined IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net) | |
| 12:13 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 12:16 | [GuS] has joined IRC ([GuS]!~MysT@unaffiliated/gus/x-663402) | |
| 12:16 | <alkisg> slin: why do you need to add a keyboard layout at all? Didn't your chroot inherit your server's settings? Or you didn't have the correct *system* keyboard layout at the server either?
| |
| 12:16 | [GuS] has left IRC ([GuS]!~MysT@unaffiliated/gus/x-663402, Read error: Connection reset by peer) | |
| 12:17 | [GuS] has joined IRC ([GuS]!~MysT@unaffiliated/gus/x-663402) | |
| 12:18 | [GuS] has joined IRC ([GuS]!~MysT@unaffiliated/gus/x-663402) | |
| 12:21 | <andygraybeal> yea, i'm assuming i should go with the classic gnome!
| |
| 12:22 | otherwise, i might upset people! but i am only assuming.
| |
| 12:30 | <alkisg> Meh damn Ubuntu diffs from Debian. I fixed the keyboard problem in http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/2072, but only for Debian. :(
| |
| 12:39 | slin: if you copy /etc/default/keyboard from your server to your chroot it should be OK. I'll commit a fix in a while.
| |
| 12:40 | <slin> alkisg: no, due ppl switcing keyboards :)
| |
| 12:40 | wow, let me check that fix
| |
| 12:40 | hmmm. any idea why skype has audio problems while the system sounds are working fine?
| |
| 12:41 | skype just says problem with audio playback
| |
| 12:41 | while youtube is also fine
| |
| 12:43 | hm. might be i will give a try to build nbd image from ltsp upstream
| |
| 12:43 | <alkisg> What do you mean by that?
| |
| 12:44 | Most Ubuntu specific code is already upstream, if you're talking about what I said earlier about the Debian diffs
| |
| 12:44 | <slin> ah
| |
| 12:44 | Gremble has joined IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com) | |
| 12:45 | <alkisg> I wasn't complaining about Ubuntu's LTSP, but about Ubuntu diffs from Debian in general
| |
| 12:45 | <slin> i just wondering about this keyboard layout issue ;) might be this caused by my LTSP client image is old? was generated by my old 9.4
| |
| 12:45 | <alkisg> You're supposed to build new chroots on each new Ubuntu series
| |
| 12:45 | That will change from 12.04 on, where you'll be able to upgrade them
| |
| 12:46 | <slin> ok. just to clear, i have a 11.10 TEST, and a 10.4? (karmic)
| |
| 12:46 | and the ltsp images are build by the karmic
| |
| 12:47 | let me install one new in vmware and build new images
| |
| 12:47 | might be it will solve my skype issue as well
| |
| 12:47 | <alkisg> 10.04 is Lucid
| |
| 12:48 | <slin> ok. then its a 9.10, before :)
| |
| 12:48 | sep has joined IRC (sep!~sep@40.211.jostedal.no) | |
| 12:48 | zoobab has left IRC (zoobab!zoobab@vic.ffii.org, Ping timeout: 245 seconds) | |
| 12:49 | <alkisg> slin: did you file a bug report that I should close once I fix the keyboard problem?
| |
| 12:49 | <andygraybeal> yay, bug reports!
| |
| 12:50 | <slin> had no time yet, walking around the users
| |
| 12:50 | <alkisg> ok
| |
| 12:50 | <slin> also want to reproduce this with new ltsp client images
| |
| 12:50 | <alkisg> I just did
| |
| 12:50 | And I also verified the fix
| |
| 12:52 | <highvoltage> good morning
| |
| 12:52 | <slin> gm
| |
| 12:53 | bauerski has left IRC (bauerski!~witekb@frodo.psp.opole.pl, Quit: Leaving.) | |
| 12:54 | bauerski has joined IRC (bauerski!~witekb@frodo.psp.opole.pl) | |
| 12:58 | zoobab_ has joined IRC (zoobab_!zoobab@vic.ffii.org) | |
| 13:00 | bengoa has joined IRC (bengoa!~bengoa@2001:1291:229:2:216:cbff:feab:6cc9) | |
| 13:06 | <alkisg> Does any non-Debian distro have any of those 2 files? /etc/default/console-setup, /etc/default/keyboard
| |
| 13:07 | <Hyperbyte> To be honest, I don't think any non-Debian distros really use /etc/default
| |
| 13:08 | It's a Debian thing I think. Fedora uses /etc/sysconfig for that kind of stuff, although I do have "grub", "nss" and "useradd" in my /etc/default/ on Fedora 16.
| |
| 13:08 | <alkisg> OK, so I did well to put that code only under init-ltsp.d/Debian :)
| |
| 13:08 | ty
| |
| 13:10 | bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) | |
| 13:10 | <alkisg> slin: fixed in http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ltsp-trunk/revision/2155
| |
| 13:11 | A new LTSP version will be released for Ubuntu 12.04 in a few days, I believe it will contain those fixes too
| |
| 13:11 | <slin> cool
| |
| 13:11 | will it backward compatible, so not needed to host two nbd bootimage?
| |
| 13:12 | <alkisg> What do you mean? What's your desired server + chroot versions?
| |
| 13:13 | <slin> i need a 12.4 for testing, and one 9.4 as current system till i switch the users over
| |
| 13:13 | <alkisg> Do you want to serve a 12.04 chroot from a 9.04 server?
| |
| 13:13 | Or a 12.04 chroot from a 12.04 server?
| |
| 13:14 | <slin> i have a dedicated boot server, what is 9.04 atm and holds the boot images
| |
| 13:15 | and two app servers, one 64bit 11.10 - this will be the 12.04 , and one 9.10 what will be replaced by 12.04 as well once its ok for the users
| |
| 13:17 | but this is not an issue, will solve. generate the boot images on the proper server and transfer to the bootserver
| |
| 13:17 | can i somehow configure the thinclients to pick up what boot image?
| |
| 13:17 | <alkisg> There was a big change in recent nbd versions, it started supporting named exports instead of port based exports
| |
| 13:18 | I think that will be your only trouble
| |
| 13:18 | <slin> ok. is any recent rtfm about? i could reach docs only from 2009
| |
| 13:19 | <alkisg> NBD docs? Check its man page
| |
| 13:20 | <slin> hmm. might be i'll fire up a separated tftp server where my test clients can boot from, that is the cleanest
| |
| 13:20 | so keep separated the old and the new system
| |
| 13:23 | bauerski has left IRC (bauerski!~witekb@frodo.psp.opole.pl, Quit: Leaving.) | |
| 13:26 | ry has joined IRC (ry!~ry@static-71-183-64-28.nycmny.fios.verizon.net) | |
| 13:35 | risca has joined IRC (risca!~risca@wi-secure-2252.cc.umanitoba.ca) | |
| 13:43 | sep has left IRC (sep!~sep@40.211.jostedal.no, Ping timeout: 244 seconds) | |
| 13:54 | dead_inside has joined IRC (dead_inside!~dead_insi@76.75.3.174) | |
| 13:56 | Da-Geek has joined IRC (Da-Geek!~Da-Geek@94.236.7.190) | |
| 13:59 | Da-Geek has left IRC (Da-Geek!~Da-Geek@94.236.7.190, Client Quit) | |
| 14:04 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 240 seconds) | |
| 14:23 | <stgraber> alkisg: how important is X_COLOR_DEPTH=16 for you? I'm a bit worried of it breaking compiz, highvoltage and mgariepy are still doing tests AFAIK but it doesn't look good so far
| |
| 14:23 | alkisg: would it be a problem for you if we revert the change and just recommend it as a performance optimization for people who can do it (like LDM_DIRECTX)?
| |
| 14:23 | <alkisg> stgraber: it's not; as long as X_SMART_COLOR_DEPTH is supported, I don't mind if it's false by default
| |
| 14:24 | Just change X_SMART_COLOR_DEPTH:-True to X_SMART_COLOR_DEPTH:-False in the source
| |
| 14:24 | But does it break compiz? On which cards?
| |
| 14:24 | <stgraber> alkisg: intel 945 from what I understood yesterday of my discussion with highvoltage
| |
| 14:25 | <alkisg> Let me test locally...
| |
| 14:25 | <stgraber> so the most common intel graphic chipset
| |
| 14:25 | <alkisg> But that would be a major bug for compiz then :)
| |
| 14:25 | <stgraber> that'd be a bug, not sure they'd consider it major though (even if it'd be for us ;))
| |
| 14:26 | risca has left IRC (risca!~risca@wi-secure-2252.cc.umanitoba.ca, Ping timeout: 248 seconds) | |
| 14:26 | <alkisg> OK give me a few minutes to test with my daughter's laptop, if it breaks then sure let's revert it
| |
| 14:27 | But please let's keep support for X_SMART_COLOR_DEPTH, even if it's False by default
| |
| 14:28 | <stgraber> sure, keeping the option is perfectly fine and we can certainly document it as a nice performance boost for cases where it works
| |
| 14:29 | <alkisg> Hmm for some reason I can't get unity, I'm getting -2d... looking why...
| |
| 14:29 | (with 32bpp)
| |
| 14:30 | 00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GSE Express Integrated Graphics Controller [8086:27ae] (rev 03), Subsystem: Intel Corporation Device [8086:1999], Kernel driver in use: i915
| |
| 14:31 | <mgariepy> it breaks compiz on 10.04 when i added X_ARGS="-depth 16 -nr"
| |
| 14:31 | <alkisg> x-session-manager[1941]: WARNING: Session 'ubuntu' runnable check failed: Failed to execute child process "/usr/lib/nux/unity_support_test" (No such file or directory)
| |
| 14:32 | Ah sorry I'm testing fat, not thin
| |
| 14:38 | I can't get unity to run: /usr/lib/nux/unity_support_test -p ==> Not software rendered: no
| |
| 14:38 | ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Excess Flood) | |
| 14:38 | bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) | |
| 14:39 | <alkisg> glxinfo => direct rendering: Yes
| |
| 14:39 | ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de) | |
| 14:42 | <alkisg> mgariepy: have you tried with 12.04?
| |
| 14:43 | And, how does it break? Crash? Or some error that it refuses to load?
| |
| 14:45 | <highvoltage> alkisg: yeah a colour depth of 16 bits breaks any thin client that uses compiz for window manager as well (which we like to use on LTSP because of better thin client performance and reduced network overhead)
| |
| 14:45 | (oh mgariepy already covered that)
| |
| 14:48 | <alkisg> highvoltage: on 12.04 too?
| |
| 14:48 | <mgariepy> alkisg, not tested on 12.04
| |
| 14:48 | <alkisg> Maybe compiz has been fixed since 10.04...
| |
| 14:49 | mcfloppy has joined IRC (mcfloppy!~kvirc@95-88-45-130-dynip.superkabel.de) | |
| 14:49 | <mcfloppy> hello
| |
| 14:49 | * alkisg tests with another intel-based laptop... | |
| 14:49 | <mgariepy> alkisg, i'll be able to test that next week
| |
| 14:49 | <Hyperbyte> mcfloppy!
| |
| 14:49 | <mgariepy> not next but the other one after ... :S
| |
| 14:49 | <highvoltage> alkisg: I doubt it will work, but I will try
| |
| 14:49 | <mcfloppy> Hyperbyte? :)
| |
| 14:50 | <Hyperbyte> Hiiiii! :-D
| |
| 14:50 | <mcfloppy> Hiiiiii ;)
| |
| 14:50 | <alkisg> highvoltage, mgariepy, with 2 intel laptops here I fail to get unity running, so if that's not a local problem, then the color depth is the least of your problems... :)
| |
| 14:50 | Not software rendered: No
| |
| 14:50 | Maybe they started checking for remote X
| |
| 14:51 | <highvoltage> alkisg: we use gnome fallback with compiz, we don't particularly care about unity on ltsp
| |
| 14:51 | (although I guess we should since we ship it on edubuntu by default :p)
| |
| 14:51 | <alkisg> highvoltage: how do I do that?
| |
| 14:51 | If I just choose gnome-fallback, is that enough?
| |
| 14:52 | * mcfloppy drinks now a coffee and eat a tussocker to quit the first work | |
| 14:52 | <mcfloppy> ;)
| |
| 14:52 | <highvoltage> alkisg: nope, we used to change the gconf key to replace metacity with compiz, last when I tested it with 12.04 I added a compiz --replace somewhere, it's on my todo list to check the proper way of doing that
| |
| 14:53 | <mcfloppy> now i go to my second job... administrator in mothers small business ;)
| |
| 14:53 | <alkisg> highvoltage: but since it requires a lot of fiddling to get working, how hard would it be for you to just add X_SMART_COLOR_DEPTH=False in lts.conf?
| |
| 14:55 | I'm on gnome-fallback, tried compiz -replace, it started, flashed for a few seconds, and then crashed with apport dialog. On 32 bpp.
| |
| 14:55 | <highvoltage> alkisg: not hard at all, but we shouldn't make it harder for people who want to use unity (which is shipped by default in ubuntu/edubuntu) either, imho
| |
| 14:55 | <alkisg> highvoltage: but unity doesn't work at all with remote X anymore
| |
| 14:55 | <highvoltage> ah compiz works fine for me on gnome fallback
| |
| 14:56 | <alkisg> So, why make performance suffer for the default unity-2d case, just to make it 1 line easier for people that manage to get either unity or compiz working?
| |
| 14:56 | <highvoltage> alkisg: I'm aware of that, and I'm hoping that someone else will fix it :)
| |
| 14:57 | alkisg: do you have actual performance numbers to share? (like, even humanly viewed numbers in ethstatus or something) of typical bandwidth usage between 16bit and 32bit use?
| |
| 14:58 | <alkisg> highvoltage: yes, it's 50%
| |
| 14:58 | I posted examples in the mailing list
| |
| 14:58 | Mava has left IRC (Mava!~Mava@ip-45-224.dhcp.opintanner.fi, Remote host closed the connection) | |
| 14:58 | <alkisg> (ltsp-discuss, we've been talking about it for a week now)
| |
| 14:58 | So from 75 mbps for a normal non-full screen youtube video you go to 38
| |
| 14:59 | <highvoltage> ah, I'll go look it up, I had to skim through the thread since it's gotten prety big
| |
| 14:59 | <alkisg> It's on the first post
| |
| 14:59 | highvoltage: you're not running compiz locally, but remotely on the server, right?
| |
| 14:59 | <highvoltage> alkisg: it sounds logical to use 16bpp for ltsp, but it shouldn't hurt stability. you're meaning for this to go into 12.04, right?
| |
| 15:00 | <alkisg> Yes
| |
| 15:00 | <highvoltage> alkisg: yes, compiz runs locally
| |
| 15:00 | <alkisg> Ah, so it needs to be installed in the chroot etc
| |
| 15:00 | <Hyperbyte> highvoltage, I can tell you that full-screen flash video works at ~15fps on a 1920x1080 display, as opposed to with ~2fps
| |
| 15:00 | <alkisg> That's too far away from the default installation
| |
| 15:00 | I wouldn't want to hurt the default installation so much just to prevent users that do that from a 1 line change in lts.conf
| |
| 15:00 | <highvoltage> alkisg: well, it's not my choice, if it were I'd be happy with 16bpp as well
| |
| 15:01 | <alkisg> highvoltage: but why is it a problem for you to put 1 line in lts.conf? X_SMART_COLOR_DEPTH=False
| |
| 15:01 | <highvoltage> alkisg: I'd also want to make sure it's safe, too
| |
| 15:01 | alkisg: it isn't
| |
| 15:03 | <alkisg> OK so let's sum up. By default, unity isn't working for precise, and unity-2d is used. So 16bpp would help with the default installation, and even with gnome-fallback.
| |
| 15:03 | Now if one wants to run compiz locally, he wants 32bpp. But that's a rare use case, and we can document the lts.conf 1 line change along with a how-to-run-compiz locally. Correct?
| |
| 15:05 | <highvoltage> alkisg: correct.
| |
| 15:06 | <alkisg> stgraber: so I believe that the default X_SMART_COLOR_DEPTH should stay to True, until problems are reported with it with the default installation
| |
| 15:06 | * alkisg got local compiz working, will test with 16bpp on 12.04... | |
| 15:08 | <highvoltage> (I'm just going through the thread again, just a few moments...)
| |
| 15:08 | <stgraber> alkisg: I haven't read the whole backlog, but this sounds like a dangerous change to do that late in the cycle, so unless we have it fully tested by next upload (Friday), I'll set it to False by default in the Ubuntu packaging
| |
| 15:09 | <alkisg> stgraber: it's been tested in 250 schools for the last 2 years
| |
| 15:10 | <stgraber> alkisg: yeah, I know that -depth 16 is safe when using metacity and none of the new fancy stuff, Revolution Linux has been setting that for years too
| |
| 15:10 | <alkisg> stgraber: the new fancy stuff (i.e. unity) doesn't work for thin clients anymore, even on 32bpp
| |
| 15:10 | <stgraber> alkisg: what worries me is the behaviour with the default environment when running opengl/compiz/clutter/...
| |
| 15:11 | <highvoltage> alkisg: personally I think it would be ok if the documentation very explicitly says that users with intel 8xx chips should set the colour depth manually
| |
| 15:11 | alkisg: I realise it's an old chipset, but people tend to use old computers for ltsp, and computers using those chips are usually otherwise ok for ltsp
| |
| 15:12 | <alkisg> glxgears runs fine with 16bpp, compiz doesn't crash but has severe rendering issues
| |
| 15:12 | TatankaT_ has left IRC (TatankaT_!~tim@peno.cwlab.kotnet.org, Quit: Lost terminal) | |
| 15:12 | <alkisg> highvoltage: 8xx was broken on 10.04 even without ltsp
| |
| 15:12 | <highvoltage> alkisg: ok in that case it doesn't matter
| |
| 15:13 | <alkisg> You couldn't start X without a patched kernel + ppa for xserver-xorg-intel
| |
| 15:13 | <highvoltage> alkisg: and it still hasn't worked since then?
| |
| 15:13 | <alkisg> In 11.04 they reverted to using vesa, (blacklisting),
| |
| 15:13 | (or fbdev, not sure)
| |
| 15:13 | <highvoltage> ew, ok. will in that case 8xx is completely irrelevant
| |
| 15:14 | <alkisg> and I think that in 11.10 they started using the intel driver again but without xvideo etc
| |
| 15:14 | The chipset had cache coherency problems which were very difficult to solve properly
| |
| 15:15 | OK, so I verified that compiz doesn't work well with 16bpp in 12.04/i945. But glxgears works fine. Let me try gnome-shell...
| |
| 15:15 | <highvoltage> 16bpp by default sounds great, but I think stgraber is completely rational in being cautious in wanting to change it at this stage in the cycle
| |
| 15:15 | TatankaT has joined IRC (TatankaT!~tim@peno.cwlab.kotnet.org) | |
| 15:16 | <alkisg> highvoltage: but see the mailing list thread, most people edit lts.conf to revert back to 16bpp ever since it was changed a few years back
| |
| 15:16 | (the default used to be 16bpp)
| |
| 15:17 | For 16bpp/gnome-shell, I automatically got gnome-fallback: gnome-session-is-accelerated: No hardware 3D support.
| |
| 15:17 | Trying 32bpp...
| |
| 15:18 | <highvoltage> it would be nice to have a 'common issues' section on the ltsp website for people who would run into problems with something like that
| |
| 15:18 | because it does indeed seem like they'd be in the minority
| |
| 15:18 | <alkisg> Yes that would be indeed very nice
| |
| 15:19 | gnome-fallback too
| |
| 15:20 | stgraber: so, neither unity nor gnome-shell run in thin clients, unity-2d or gnome-fallback are automatically used
| |
| 15:20 | Which makes the point about 16bpp compatibility moot
| |
| 15:21 | <stgraber> alkisg: hmm, I need to look at unity and why it doesn't start. We definitely want compiz working on 12.04, I'll have a look this afternoon
| |
| 15:21 | we used to have a LTSP hook for that which got deprecated but may need to be re-added in an updated way
| |
| 15:21 | <alkisg> compiz does work if ran locally, but that's a rare use case which requires fiddling anyway, so a 1-line edit isn't much to ask there
| |
| 15:24 | <stgraber> compiz used to work when ran remotely, if it doesn't anymore, it's a regression that needs fixing
| |
| 15:24 | <||cw> I don't even have any clients capable of running of compiz reasonably locally :/
| |
| 15:24 | <alkisg> stgraber: did it run fast enough when ran remotely for people to want to actually use it?
| |
| 15:25 | <||cw> that was my next question, wouldn't it require gigabit?
| |
| 15:25 | <alkisg> I mean, it might be best *not* to fix it, if it's too slow, so that thin clients do use unity-2d
| |
| 15:25 | <stgraber> alkisg: it was making the desktop faster than with metacity and reducing bandwidth usage in half
| |
| 15:25 | <||cw> thin clients are supposed to be light, and the 100Mbit network is often the bottleneck anyway
| |
| 15:25 | <alkisg> stgraber: I think you're thinking about local compiz there, when you mention bandwidth
| |
| 15:26 | <stgraber> alkisg: no
| |
| 15:26 | <alkisg> I really doubt remote compiz would take less bandwidth than metacity
| |
| 15:26 | <stgraber> alkisg: compiz ran remotely was saving bandwidth as it was using the local X server to do texture caching
| |
| 15:26 | <||cw> interesting
| |
| 15:26 | <stgraber> alkisg: where raw X would just send the texture again every time you move a window or do anything
| |
| 15:26 | alkisg: the use of compositing saves quite a bit of bandwidth wherever you run compiz and that's why we made it work to start with
| |
| 15:27 | <alkisg> When I tried compiz --replace, it flashed etc but it did work for a few seconds. I tried moving around windows and saw that it was incredibly slow. Maybe due to its problems, dunno.
| |
| 15:28 | OK, let's do some benchmarks if you manage to get it fixed
| |
| 15:28 | <stgraber> alkisg: anyway, testing with my usual thin client now (that used to be running compiz just fine), will try to make compiz work again
| |
| 15:28 | <alkisg> If it's not fixed though, I'd really prefer the default to be 16bpp (not for our schools here, we ship an lts.conf anyway, for the rest of the ltsp users)
| |
| 15:34 | staffencasa has joined IRC (staffencasa!~staffenca@128-193-148-207.oregonstate.edu) | |
| 15:36 | dobber has left IRC (dobber!~dobber@213.169.45.222, Remote host closed the connection) | |
| 15:40 | alexqwesa has left IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net, Ping timeout: 260 seconds) | |
| 15:41 | alexqwesa has joined IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net) | |
| 15:42 | <stgraber> alkisg: ok, got compiz to start but with glitches, now trying to get it clean :)
| |
| 15:43 | <alkisg> stgraber: should I file a bug about compiz not working on 16bpp, or it's already known + ignored by the devs?
| |
| 15:44 | Because that would be best, it would keep the overall bandwidth to 50%
| |
| 15:44 | Youtube videos and all considered
| |
| 15:44 | I don't think it would be very hard, it's working already but with rendering issues, no crashes though
| |
| 15:45 | <stgraber> alkisg: ok, the problem is that we use llvmpipe as rasterizer instead of the intel one, that explains why it's currently slow and glitchy
| |
| 15:45 | <alkisg> Ah, I did see that llvmpipe in the logs
| |
| 15:46 | sep has joined IRC (sep!~sep@40.211.jostedal.no) | |
| 15:46 | <alkisg> Maybe that rasterizer change could solve the 16bpp rendering issues too
| |
| 15:46 | <stgraber> alkisg: done, compiz is working here
| |
| 15:46 | alkisg: set LDM_DIRECTX=true, then run: LIBGL_ALWAYS_INDIRECT=1 compiz --replace
| |
| 15:46 | <alkisg> OK, let me try...
| |
| 15:48 | <stgraber> I'm pretty sure we had direct rendering working at some point though...
| |
| 15:48 | I'm not sure what kind of bandwidth usage we'll get with indirect rendering
| |
| 15:49 | and I haven't tested -depth 16 yet, maybe that'll work with indirect
| |
| 15:52 | alkisg: in 24bit, bandwidth usage when shaking a window really quickly goes up to a megabit, so really pretty low
| |
| 15:58 | ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Excess Flood) | |
| 15:59 | ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de) | |
| 16:04 | Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.71, Quit: "Achievement is not the end, its the beginning of new journey !!!") | |
| 16:06 | <alkisg> (sorry long phone...) Compiz worked fine for me too on 32bpp, trying on 16...
| |
| 16:08 | stgraber: nope, same rendering issues with remote compiz on 16bpp. I'll file a bug about that.
| |
| 16:10 | <stgraber> sadly unity won't work with indirect rendering as it requires a GL function that's not available in mesa's indirect rendering engine
| |
| 16:11 | but you can run gnome-fallback with compiz though or maybe even unity-2d with compiz
| |
| 16:11 | I'm installing gnome-shell now to see if it works with indirect rendering
| |
| 16:13 | in any case, we should set LIBGL_ALWAYS_INDIRECT in LTSP, I can't see any side effect of having working GL for some clients
| |
| 16:14 | alkisg: as for 16bit, one trick we could do is make the default 16bit when you don't have LDM_DIRECTX=true but not set it when LDM_DIRECTX is set (forcing the users to define it in that case)
| |
| 16:15 | so that way we reduce the bandwidth usage when running over SSH but we don't break cases where 16bit fails (gl, compiz, ...) as these require DIRECTX anyway
| |
| 16:15 | <alkisg> stgraber: since compiz doesn't work out of the box, I'd still prefer SMART_X_COLOR_DEPTH=True by default, and some how-to to get compiz running that mentions those 2 changes
| |
| 16:16 | Also, most people that set 16bpp also use LDM_DIRECTX=True
| |
| 16:17 | Filed bug for compiz: https://bugs.launchpad.net/compiz-core/+bug/967263
| |
| 16:18 | <stgraber> alkisg: I just pushed LIBGL_ALWAYS_INDIRECT support to ldm-trunk
| |
| 16:19 | neyder_ has joined IRC (neyder_!~neyder@201.240.89.218) | |
| 16:19 | <alkisg> stgraber: I think that will badly affect other 3d apps
| |
| 16:19 | <stgraber> if by badly affect, you mean making them work without using the CPU of the server, yeah, it'll "badly affect" them
| |
| 16:19 | <alkisg> It's compiz that's broken, not 3d in general
| |
| 16:20 | <stgraber> no, 3d is broken in general for remote apps
| |
| 16:20 | it's not compiz's fault that mesa uses llvmpipe (software rendering) and requires LIBGL_ALWAYS_INDIRECT
| |
| 16:20 | <slin> hmm
| |
| 16:20 | alkisg: skype 2.2 can suck my dick
| |
| 16:21 | <stgraber> running glxinfo without LIBGL_ALWAYS_INDIRECT on any thin client will tell you it's running with software rendering
| |
| 16:21 | <slin> the same LTS bootimage working fine with 2.1 ;) 2.2 says audio hw error
| |
| 16:21 | <stgraber> setting LIBGL_ALWAYS_INDIRECT instead uses the client's video card, so quite a bit better in all cases
| |
| 16:21 | <alkisg> stgraber: (05:39:08 μμ) alkisg: glxinfo => direct rendering: Yes
| |
| 16:21 | <stgraber> and software is supposed to detect and fallback to software rendering if it doesn't support indirect rendering (as unity does)
| |
| 16:21 | alkisg: that's with running it on the server?
| |
| 16:22 | <alkisg> stgraber: yes
| |
| 16:22 | (via the thin client of course)
| |
| 16:22 | <stgraber> alkisg: can you paste the whole glxinfo output?
| |
| 16:22 | alkisg: also, is that 12.04 and what video card?
| |
| 16:22 | <alkisg> 12.04, intel 945
| |
| 16:23 | Let me reboot to 32bpp to paste glxinfo...
| |
| 16:23 | <stgraber> ok, that's really weird... I'm also testing on a 945
| |
| 16:23 | alkisg: is that llvmpipe?
| |
| 16:23 | I "think" llvmpipe might say it's "direct rendering" as it's essentially simulting a gpu in the server's cpu...
| |
| 16:24 | <alkisg> Ah, that's very possible
| |
| 16:24 | <stgraber> if that's llvmpipe, then LIBGL_ALWAYS_INDIRECT is still the right thing to do
| |
| 16:24 | <alkisg> glxgears runs fine, but when ran fullscreen, it's slow
| |
| 16:24 | <stgraber> yeah ...
| |
| 16:24 | llvmpipe is pretty good actually, it can run gnome-shell and compiz (well a bit glitchy as you noticed) all using the server's CPU
| |
| 16:24 | just don't try to run more than 10 of these ;)
| |
| 16:25 | we had unity running with it earlier this cycle, it worked but was using 20% of cpu just for the rendering. I asked for it to be disabled in unity because of LTSP
| |
| 16:25 | <alkisg> stgraber: so the plan is to push the ldm change, and have people using the gnome-fallback session, which will get a working compiz without any setting modifications?
| |
| 16:26 | <stgraber> alkisg: gnome-fallback requires a setting to run compiz but yeah, it'll work without having to do any ltsp-specific change. In theory gnome-shell might work out of the box with my change too
| |
| 16:26 | I'm still testing that bit
| |
| 16:26 | <alkisg> stgraber: http://paste.ubuntu.com/904154/
| |
| 16:26 | OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x300)
| |
| 16:27 | <stgraber> right, that's fake direct rendering using your server's cpu :)
| |
| 16:27 | <alkisg> Gotcha
| |
| 16:28 | But if a setting is required to run compiz, I'd still prefer X_SMART_COLOR_DEPTH=True. Doing 2 changes vs 1 doesn't matter much as opposed to doing 1 change instead of 0.
| |
| 16:28 | And personally I'd prefer 50% less bandwidth for youtube videos than compiz
| |
| 16:28 | Students don't move windows around much; but they do have animated window contents
| |
| 16:29 | The ideal case of course is for the 16bpp compiz bug to be solved
| |
| 16:30 | But I think that 50% network bandwidth for window contents is more important for most ltsp users
| |
| 16:31 | [GuS] has joined IRC ([GuS]!~MysT@unaffiliated/gus/x-663402) | |
| 16:31 | <alkisg> Dragging a window around *without* compiz only needs 1.7 mbps
| |
| 16:31 | While youtube goes to 75 from 38
| |
| 16:31 | So 0.1 mbps difference from compiz vs 38 mbps from youtube, I vote for the second
| |
| 16:35 | <stgraber> oh, fun, gnome-shell doesn't like LTSP apparently, it simply segfaults at startup :)
| |
| 16:35 | but gnome-fallback + compiz works great
| |
| 16:35 | <alkisg> stgraber: what's that setting to automatically enable compiz on classic gnome?
| |
| 16:36 | <stgraber> highvoltage: ^
| |
| 16:36 | btw, I'm playing fullscreen openarena running on the SERVER over the network with compiz + LIBGL_ALWAYS_INDIRECT :)
| |
| 16:36 | try to do that with the software rendering
| |
| 16:37 | (ok, it's using 40mbps just for that, but still, it works!)
| |
| 16:38 | getting around 30fps playing fullscreen, reasonable
| |
| 16:38 | <alkisg> Cool!
| |
| 16:39 | <stgraber> so yeah, we definitely want LIBGL_ALWAYS_INDIRECT and it seems to work great on intel at least ;)
| |
| 16:39 | * stgraber reboots in 16bit to see how much of that would still work | |
| 16:39 | <alkisg> Anyway, for X_SMART_COLOR_DEPTH I'm still very in favor of setting it to True by default, because of the reasons I mentioned above ^. But it's your choice to make; and I ship an lts.conf anyway. :)
| |
| 16:39 | Gremble has left IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com, Quit: I Leave) | |
| 16:41 | <alkisg> LIBGL_ALWAYS_INDIRECT=1 glxgears -fullscreen => gears not moving at all
| |
| 16:42 | <stgraber> yeah, I have the same thing here but I had the same behaviour on my laptop for a while too so not really worried about it ;)
| |
| 16:43 | it still shows > 100FPS for me on the atom, it just doesn't refresh the screen for some reason
| |
| 16:43 | <alkisg> Maybe a glxgears bug...
| |
| 16:43 | <stgraber> openarea is more reliable as a real opengl software
| |
| 16:43 | <alkisg> teeworlds runs better with indirect
| |
| 16:45 | Meh, if we had the new configuration system, we could see if the gnome-classic compiz -enabling change was done and dynamically disable X_SMART_COLOR_DEPTH then
| |
| 16:45 | But I really think that for someone that does 1 change, doing another isn't much of a problem
| |
| 16:45 | It's the out of the box experience that matters most
| |
| 16:48 | <knipwim> alkisg: i have the same chroot_release()
| |
| 16:48 | it seems like the distroness depends on ltsp-chroot implementation
| |
| 16:49 | <stgraber> alkisg: can you try installing "xcompmgr" and run "xcompmgr -a", then try shaking some windows again?
| |
| 16:49 | <knipwim> so we could also check for that when determining to execute chroot_release()
| |
| 16:50 | like if [ "$verbose" = "true" ] && [ -x /usr/sbin/ltsp-chroot ]; then chroot_release
| |
| 16:50 | <stgraber> alkisg: but yeah, considering the current state of unity-3d and gnome-shell (one explicitly not supporting indirect rendering because of mesa limitation and the other just crashing), I'm not as worried as I was before
| |
| 16:51 | neyder_ has left IRC (neyder_!~neyder@201.240.89.218, Quit: Saliendo) | |
| 16:51 | <stgraber> having LIBGL_ALWAYS_INDIRECT set should at least make unity-2d use opengl rendering for most of the effects so decreasing the load a bit on the server
| |
| 16:51 | and until gnome-fallback uses compiz by default when present (if ubuntu ever does that), it's not a big concern indeed
| |
| 16:52 | though running "xcompmgr -a" does give me the same benefit as compiz but working with 16bit and without replacing the window manager
| |
| 16:52 | slin has left IRC (slin!~slinky@frugalware/developer/slin, Ping timeout: 260 seconds) | |
| 16:52 | <stgraber> so it may be useful to use it automatically as an ldm rc.d script if it's present
| |
| 16:53 | <alkisg> (07:48:53 μμ) knipwim: it seems like the distroness depends on ltsp-chroot implementation => sorry I didn't understand the "distroness" part
| |
| 16:53 | stgraber: xcompmgr locally on 16bpp? or remotely on the server?
| |
| 16:54 | <stgraber> alkisg: shouldn't matter, it's just messing with X AFAIK
| |
| 16:54 | alkisg: I ran it on the server in my case
| |
| 16:54 | alkisg: but if we choose to do it by default, it'd probably be on the client instead
| |
| 16:54 | <alkisg> stgraber: if it doesn't matter, I'd prefer it on the server, for low-ram clients
| |
| 16:56 | <stgraber> alkisg: you really care about 1.1k?
| |
| 16:56 | <alkisg> 1.1k ram? or m?
| |
| 16:57 | <stgraber> having it on the client would be easier from a packaging point of view as I don't like ltsp-server to depend on too much session stuff
| |
| 16:57 | alkisg: ram
| |
| 16:57 | <alkisg> Wow, a /bin/sh takes 0.6m...
| |
| 16:57 | <knipwim> alkisg: chroot_release() is now a distro specific release
| |
| 16:57 | erm, function
| |
| 16:58 | while it could be common
| |
| 16:58 | <stgraber> alkisg: hmm, let me triple check that I didn't mess up with the units ;)
| |
| 16:58 | <knipwim> but it's execution depending on the presence of ltsp-chroot
| |
| 16:58 | <alkisg> stgraber: user02 24215 0.0 0.0 3908 1296 pts/4 S+ 19:58 0:00 xcompmgr -a
| |
| 16:59 | <stgraber> alkisg: yeah, messed up in the units ... cat /proc/pid/status is so much easier to read ;)
| |
| 16:59 | <alkisg> Yeah that's Mb, I spend an afternoon to get rid of the openvt that took half or it :D
| |
| 16:59 | <stgraber> alkisg: so 1.1MB hre
| |
| 16:59 | <alkisg> We could re-enable cron with that much free ram :P
| |
| 16:59 | (128 mb ram clients wouldn't work anymore on 12.04)
| |
| 17:00 | I had to disable necessary services to get them not to swap too much
| |
| 17:00 | risca has joined IRC (risca!~risca@wi-secure-2901.cc.umanitoba.ca) | |
| 17:01 | <alkisg> But I think you're right, that one is best put as an ltsp-client dependency
| |
| 17:01 | As it should save a lot of bandwidth, if it does what I understood
| |
| 17:02 | <stgraber> you can probably blacklist it on low-mem systems if that's a big problem
| |
| 17:03 | <alkisg> Indeed it reduces bandwidth a lot for moving around windows, nice idea stgraber :)
| |
| 17:03 | Were will you run it from? ldm/rc.d ?
| |
| 17:04 | <stgraber> yeah
| |
| 17:05 | it should also make the desktop a bit smoother on fat clients
| |
| 17:05 | <alkisg> stgraber: just put an ` if ! boolean_is_true "$DISABLE_XCOMPMGR"` there
| |
| 17:05 | <stgraber> and I confirmed that if you start compiz on top of it, it doesn't mind
| |
| 17:05 | alkisg: k
| |
| 17:05 | <alkisg> Really? /me reads its manpage...
| |
| 17:05 | <stgraber> compositing is always good for you, even locally
| |
| 17:06 | <alkisg> stgraber: fat clients get unity-3d by default
| |
| 17:06 | <stgraber> it will turn on real transparency too (terminals, ...)
| |
| 17:06 | right, if it runs with compiz, then it won't do anything as compiz does the same thing
| |
| 17:06 | * alkisg checks how much X memory it uses... | |
| 17:08 | <stgraber> should be very low if any at all
| |
| 17:08 | added and pushed to ldm-trunk
| |
| 17:08 | <alkisg> Yeah just 1k, but where does it save the window contents to do the compositing? In the videoram?
| |
| 17:10 | <stgraber> X does the texture caching for the compositing, so anything that's on-screen likely won't take any extra memory, the difference is that what's off-screen will be cached too, so it may use a bit more memory there
| |
| 17:10 | <alkisg> I think it's worth it though :)
| |
| 17:10 | * stgraber is no X expert, just came to the conclusion that compositing is good for you as it saves bandwidth and improves performance | |
| 17:11 | <alkisg> OK so the plan is to depend on xcompmgr and to let X_SMART_COLOR_DEPTH=True by default?
| |
| 17:11 | <stgraber> yeah
| |
| 17:11 | * alkisg hugs stgraber :) | |
| 17:11 | <stgraber> I'll file the MIR for xcompmgr
| |
| 17:12 | <alkisg> knipwim: maybe some distro can just cat a chroot file instead of running ltsp-chroot?
| |
| 17:12 | E.g. cat /opt/ltsp/i386/etc/lsb_release
| |
| 17:12 | That even saves it from requiring roo
| |
| 17:12 | t
| |
| 17:12 | As it's the only part (the chroot call) that needs the same arch in the server + the chroot, and it requires root
| |
| 17:13 | So I don't really like it
| |
| 17:14 | mgariepy has left IRC (mgariepy!mgariepy@ubuntu/member/mgariepy, Remote host closed the connection) | |
| 17:14 | mgariepy has joined IRC (mgariepy!mgariepy@ubuntu/member/mgariepy) | |
| 17:16 | * highvoltage catches up | |
| 17:19 | <mcfloppy> my fat clients doesnt boot any more... after i installed kde-base in the image, they hang on: "Starting Hardware abstraction layer: hald"
| |
| 17:19 | can you help me?
| |
| 17:20 | <stgraber> MIR filed, having the release team to look at it
| |
| 17:23 | risca has left IRC (risca!~risca@wi-secure-2901.cc.umanitoba.ca, Ping timeout: 272 seconds) | |
| 17:25 | monteslu_ is now known as monteslu | |
| 17:29 | komunista has joined IRC (komunista!~slavko@adsl-195-168-230-167.dynamic.nextra.sk) | |
| 17:37 | rthomson has joined IRC (rthomson!~rthomson@mars.pet.ubc.ca) | |
| 17:53 | <mcfloppy> has nobody a idea?
| |
| 17:54 | <alkisg> mcfloppy: you installed an ubuntu chroot and later on installed kde-base?
| |
| 17:54 | <mcfloppy> alkisg: i have a debian host and a debian chroot in it
| |
| 17:54 | so i build a fat client image
| |
| 17:54 | chroot on it and install kde base
| |
| 17:55 | <alkisg> I don't use debian nor kde much so I don't know how far in the boot process that message is, a screenshot would be more helpful
| |
| 17:57 | <mcfloppy> hmm
| |
| 17:59 | <alkisg> E.g. it's possible that at that point, network management gets started, and your network connection is lost
| |
| 17:59 | Try putting a manual declaration in /etc/network/interfaces
| |
| 18:01 | <mcfloppy> hmmm okay
| |
| 18:01 | is there a way to host a kubuntu client image on a debian host?
| |
| 18:02 | or is a (k)ubuntu system at all a easy way to run a fat client system
| |
| 18:05 | <alkisg> mcfloppy: yes to both
| |
| 18:05 | Better try with a 12.04 kubuntu
| |
| 18:06 | And squeeze + backports, or wheezy
| |
| 18:06 | mcfloppy: which ltsp version do you have?
| |
| 18:09 | <highvoltage> alkisg: congrats
| |
| 18:09 | <alkisg> highvoltage: I think we all got what we wanted, which is the best for ltsp :)
| |
| 18:09 | <highvoltage> :)
| |
| 18:11 | alkisg, stgraber: I'm writing edubuntu to usb disk now, going to install it and try it on a bunch of thin clients here (also with 16bit) and see if has some problems (especially with those with crappy unichrome drivers), but I guess it will be fine
| |
| 18:11 | * alkisg has tried unicrome, work fine with 16bpp, and also don't crash now as much as they crashed on 10.04 | |
| 18:12 | <alkisg> I had to use nomodeset on 10.04
| |
| 18:12 | highvoltage: try xvideo too
| |
| 18:12 | <highvoltage> ok
| |
| 18:13 | I saw the version number increased quite a bit over the last few releases for unichrome and hoped that that meant bug fixes :)
| |
| 18:24 | <stgraber> in my experience, there isn't such a thing has "bug fixes" in unichrome, but they're good at moving them, so hopefully they move them to a part that's not used as often ;)
| |
| 18:24 | but yeah, if you want some fun, try the EDID detection code, try XV and try dual-screen
| |
| 18:24 | and run each test more than once (especially XV)
| |
| 18:24 | that's usually the how-to make a VIA crash
| |
| 18:28 | mikkel has joined IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk) | |
| 18:48 | Parker955_Away is now known as Parker955 | |
| 18:57 | slin has joined IRC (slin!~slinky@catv-89-134-70-38.catv.broadband.hu) | |
| 19:09 | <mgariepy> alkisg, we just tested 16bit over 24bit on a via thin client
| |
| 19:09 | and it doest consume as much cpu and bandwith on our setup
| |
| 19:10 | the chroot is 10.04 and the appserv is 10.10
| |
| 19:16 | <alkisg> mgariepy: you e.g. played a youtube video on 16 bpp and on 32 bpp and you got the same bandwidth stats?
| |
| 19:16 | <mgariepy> yeah
| |
| 19:16 | cap up at 80 MB
| |
| 19:17 | <alkisg> mgariepy: youtube or totem?
| |
| 19:17 | <mgariepy> youtube
| |
| 19:17 | <alkisg> No html5, no xvideo, right?
| |
| 19:17 | <mgariepy> flash crap yeah
| |
| 19:17 | <alkisg> Ah, was it full screen?
| |
| 19:17 | <mgariepy> nop
| |
| 19:17 | was the regular size.
| |
| 19:18 | <alkisg> OK let me test locally
| |
| 19:18 | But it doesn't make sense
| |
| 19:18 | <mgariepy> what's your screen resolution ? and what hardware do you have ?
| |
| 19:19 | i get 1440x900 on a via thin client
| |
| 19:19 | <alkisg> I've tested in the past with various hardware and resolutions, I'm going to test with an intel atom netbook now, 1024x600, but still larger than the youtube video to be played
| |
| 19:19 | Which is 320x240
| |
| 19:20 | mgariepy: if you want send me a video link so that we test with the same one
| |
| 19:21 | <mgariepy> from what we tested all video are doing the same
| |
| 19:21 | even slide show video
| |
| 19:21 | <alkisg> With xvideo that's to be expected, as it's the video size that matters, not the screen resolution or client color depth
| |
| 19:21 | But not with youtube, flash, and general window contents
| |
| 19:22 | OK first try, X_COLOR_DEPTH=16, LDM_DIRECTX=True
| |
| 19:23 | <mgariepy> i have X_ARGS='-depth 16'
| |
| 19:23 | and LDM_DIRECTX=True
| |
| 19:23 | X starts with -depth 16
| |
| 19:25 | <alkisg> mgariepy: btw can you also try with a video played with totem but with gstreamer-properties output set to no xv?
| |
| 19:26 | Parker955 is now known as Parker955_Away | |
| 19:27 | <alkisg> Ah the flash video is 320x240, but the window size is much larger, I can't test properly with 100mbps... hm...
| |
| 19:27 | mgariepy: gigabit or ethernet?
| |
| 19:27 | <mgariepy> 100MB
| |
| 19:28 | <alkisg> We need to test with something smaller then, to not get capped by ethernet limits
| |
| 19:28 | Maybe ctrl+- on the browser does it...
| |
| 19:29 | yes it does, mgariepy can you test again with flash but with a zoomed-out browser?
| |
| 19:29 | <mgariepy> yes give me a minute, totem just froze the thin client (i like wyse)
| |
| 19:29 | * alkisg presses ctrl+- twice and tests with that | |
| 19:30 | <alkisg> Or maybe 3 times ctrl+- to show the diff better
| |
| 19:30 | 16bpp, 50 mbps
| |
| 19:31 | <highvoltage> alkisg: alkisg you mentioned 36mbps before, on the thin client we have here it still uses 80mbps
| |
| 19:31 | <alkisg> highvoltage: that calculations were for a 320x240 window size
| |
| 19:32 | But youtube has a much larger window size even if the video is 320x280
| |
| 19:32 | In general its: width * height * frames per second * bits per pixel
| |
| 19:32 | <highvoltage> hmm, but that isn't the colour depth making a difference though
| |
| 19:32 | <alkisg> highvoltage: so me and mgariepy are testing now with a zoomed-out browser. Do you have a gigabit network?
| |
| 19:32 | <highvoltage> it's just playing faster because you're sending less pixels
| |
| 19:33 | alkisg: I'm sitting next to mgariepy looking at the same machine
| |
| 19:33 | <alkisg> highvoltage: my hypothesis is that on 32bpp you're just losing frames
| |
| 19:34 | because you're capped by 100mbps
| |
| 19:34 | <highvoltage> yeah, it's smoother on 16bpp so I can confirm that
| |
| 19:34 | slin has left IRC (slin!~slinky@catv-89-134-70-38.catv.broadband.hu, Ping timeout: 245 seconds) | |
| 19:34 | <highvoltage> but I was kind of excited about the whole 36mbps thing :(
| |
| 19:34 | <alkisg> It's true if the video (playback size, not original video size) is 320x240
| |
| 19:36 | In all cases, 16bpp should be need half the bandwidth of 32bpp
| |
| 19:36 | testing on 16bpp with 3 times ctrl+-, I get 80mbps, my network limit
| |
| 19:36 | Instead of 50 mbps with 16bpp
| |
| 19:36 | If I zoom out even more, I'll get 40mbps on 16bpp, still 80 on 32bpp
| |
| 19:37 | And of course on gigabit, a 32bpp youtube client would need e.g. 160mbps
| |
| 19:37 | Let me measure the youtube playback video size...
| |
| 19:38 | Seems something like 640x350
| |
| 19:38 | So, exact calculations:
| |
| 19:39 | monteslu_ has joined IRC (monteslu_!~monteslu@ip68-109-174-213.ph.ph.cox.net) | |
| 19:39 | <alkisg> 640×350×30×32 = 215.040.000
| |
| 19:39 | And of course the half of it for 16mbps
| |
| 19:39 | So, one youtube video caps ethernet in any case
| |
| 19:40 | But on gigabit, you can have 8x16bpp clients instead of 4x32bpp ones
| |
| 19:42 | (add a few mbps for sound in all cases)
| |
| 19:43 | monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 272 seconds) | |
| 19:44 | <alkisg> Btw, if flash was using xvideo, it would need 320x240 (the original video size, even on fullscreen) x 30 fps x 12 bpp (xvideo always uses 12 bpp) == 27.648.000
| |
| 19:45 | So one could have 35 clients watching full screen youtube with gigabit :(
| |
| 19:46 | !flash
| |
| 19:46 | <ltsp> alkisg: flash: Yes, flash sucks. Make sure you have LDM_DIRECTX=True in your lts.conf file, or if it's just youtube you're after, try some flash replacing plugin like https://addons.mozilla.org/el/firefox/addon/161869/ (per user installation, gecko-mediaplayer is also needed).
| |
| 19:48 | * alkisg tests with html5... | |
| 19:50 | risca has joined IRC (risca!~risca@wi-secure-4931.cc.umanitoba.ca) | |
| 19:54 | <alkisg> Nope, chromium-browser doesn't use xvideo either :(
| |
| 19:56 | [GuS] has left IRC ([GuS]!~MysT@unaffiliated/gus/x-663402, Remote host closed the connection) | |
| 19:57 | <alkisg> ..and neither does firefox
| |
| 20:00 | <Hyperbyte> alkisg, and neither will any other browser
| |
| 20:01 | * alkisg tries the flash replacing plugin... | |
| 20:01 | <Hyperbyte> Flash (the plugin itself) is browser independent
| |
| 20:01 | Not in the literal sense, but in the way that once it's launched, it doesn't have anything to do with the browser anymore.
| |
| 20:01 | <alkisg> Hyperbyte: I was trying youtube.com/html5, which is rendered by the browser without flash
| |
| 20:01 | <Hyperbyte> Oh!
| |
| 20:01 | Didn't know that existed
| |
| 20:01 | That's a nice step forward! Go Google!
| |
| 20:04 | <alkisg> I think that when I last tried that plugin, it indeed used xv, which is GREAT for ltsp, but it had other problems (some times not working, some others had to download all the video before starting playback... :()
| |
| 20:08 | highvoltage, mgariepy, Hyperbyte: indeed, the flash replacer plugin uses xv so it solves all of our problems, *when* it works :)
| |
| 20:08 | <Hyperbyte> alkisg, it doesn't actually
| |
| 20:08 | Unless it can be made to only work with YouTube
| |
| 20:09 | It replaces flash on all other websites too, and there it doesn't work 99% of the time.
| |
| 20:09 | <alkisg> Hyperbyte: what do you mean? It only replaces video tags that it knows
| |
| 20:09 | But yeah I know those plugins have a lot of other problems
| |
| 20:09 | <Hyperbyte> When I tried Flash replacer plugin it tried to emulate flash on every site and failed badly
| |
| 20:09 | <alkisg> It'd be very nice if browsers started showing html5 video with xv
| |
| 20:09 | <Hyperbyte> Could be different plugin though
| |
| 20:10 | alkisg, since most popular browsers are java based, I think that's gonna be a problem?
| |
| 20:10 | <alkisg> java based?! What gave you that idea?
| |
| 20:10 | <Hyperbyte> ehm
| |
| 20:10 | Lots of things
| |
| 20:10 | a23451a has joined IRC (a23451a!b85bdb19@gateway/web/freenode/ip.184.91.219.25) | |
| 20:10 | <alkisg> You don't mean javascript, you do mean java?
| |
| 20:10 | <||cw> such as?
| |
| 20:11 | <Hyperbyte> Isn't it?
| |
| 20:11 | I thought Opera, Firefox were java applications.
| |
| 20:11 | <||cw> no, there's a lot of javascript, and XUL, but not java
| |
| 20:11 | <alkisg> Hyperbyte: nope, no java related at all
| |
| 20:11 | <Hyperbyte> mhm
| |
| 20:11 | <alkisg> They only support java as a plugin, in the same sense as flash
| |
| 20:11 | <Hyperbyte> Then maybe I'm confusing the mobile versions
| |
| 20:12 | <||cw> I don't know about Opera, firefox is a XUL application
| |
| 20:12 | <Hyperbyte> I know for a fact those are java.
| |
| 20:12 | <||cw> most everything on phone is java, yes
| |
| 20:12 | <alkisg> I don't know about mobile apps :)
| |
| 20:12 | <||cw> even andriods, but not iphones,
| |
| 20:13 | <stgraber> mgariepy: all LVDS patches have been commited to the ubuntu kernel git tree, will be in next upload (probably next week)
| |
| 20:13 | <Hyperbyte> Major confusion here then in my brain. I could swear Thunderbird, Firefox were java...
| |
| 20:14 | <highvoltage> alkisg: ah I see (sorry I'm having one of those days where I'm just playing catch-up with everything all the time :) )
| |
| 20:14 | <alkisg> np :)
| |
| 20:14 | Hyperbyte: thunderbird, firefox etc implemented their own GUI in C which is called XUL
| |
| 20:15 | And opera also has implemented a gui of its own
| |
| 20:15 | chromium-browser uses webkit for rendering, I don't know if it uses that for the rest of its gui as well
| |
| 20:15 | (webkit is C too)
| |
| 20:20 | <||cw> XUL's language is javascript-like, or based, or just is, which looks a lot like java but totally isn't
| |
| 20:22 | a12334a has joined IRC (a12334a!b85bdb19@gateway/web/freenode/ip.184.91.219.25) | |
| 20:23 | a23451a has left IRC (a23451a!b85bdb19@gateway/web/freenode/ip.184.91.219.25, Ping timeout: 245 seconds) | |
| 20:49 | markit has joined IRC (markit!~marco@88-149-177-66.staticnet.ngi.it) | |
| 20:58 | bengoa has left IRC (bengoa!~bengoa@2001:1291:229:2:216:cbff:feab:6cc9, Quit: Leaving.) | |
| 20:58 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 21:02 | mikkel has left IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk, Quit: Leaving) | |
| 21:08 | vagrantc has joined IRC (vagrantc!~vagrant@75-150-46-245-Oregon.hfc.comcastbusiness.net) | |
| 21:24 | <stgraber> hey vagrantc
| |
| 21:24 | vagrantc: do you think you could upload a new ldm sometime this week (as in, tag + upload)?
| |
| 21:25 | vagrantc: we have one more wwm fix and two performance fixes in the branch at the moment that I'd like to see in Precise very soon
| |
| 21:26 | <vagrantc> stgraber: thurs evening or fri morning?
| |
| 21:26 | <stgraber> vagrantc: sounds good (whichever)
| |
| 21:26 | <vagrantc> stgraber: is the wwm one a security issue?
| |
| 21:27 | <stgraber> no, it's just also disabling all mouse actions
| |
| 21:29 | <vagrantc> and some GL/compmgr changes?
| |
| 21:32 | <stgraber> yeah, basically setting LIBGL_ALWAYS_INDIRECT so that opengl works on thin clients again
| |
| 21:32 | and running "xcompmgr -a" if it exists on the thin client
| |
| 21:32 | <vagrantc> only for LDM_DIRECTX ?
| |
| 21:32 | <stgraber> the LIBGL_ALWAYS_INDIRECT, yes as it doesn't really work otherwise
| |
| 21:32 | xcompmgr is always called unless we have disabled it through a lts.conf key
| |
| 21:32 | <vagrantc> don't know much about either, really.
| |
| 21:33 | <stgraber> xcompmgr can save up to 50% bandwidth when moving windows around
| |
| 21:33 | <vagrantc> nice.
| |
| 21:33 | <stgraber> LIBGL_ALWAYS_INDIRECT can save up to 99% bandwidth and a lot of CPU on the server for anything doing 3D stuff with a client capable of 3D rendering
| |
| 21:33 | mcfloppy has left IRC (mcfloppy!~kvirc@95-88-45-130-dynip.superkabel.de, Ping timeout: 252 seconds) | |
| 21:34 | <stgraber> with these two I managed to run openarena on an atom netbook while using around 30Mb/s and still get around 30FPS
| |
| 21:35 | <vagrantc> sounds fancy.
| |
| 22:09 | risca has left IRC (risca!~risca@wi-secure-4931.cc.umanitoba.ca, Quit: Lämnar) | |
| 22:19 | a12334a has left IRC (a12334a!b85bdb19@gateway/web/freenode/ip.184.91.219.25, Quit: Page closed) | |
| 22:25 | komunista has left IRC (komunista!~slavko@adsl-195-168-230-167.dynamic.nextra.sk, Quit: Leaving.) | |
| 22:30 | [GuS] has joined IRC ([GuS]!~gustavo@190.55.139.179) | |
| 22:30 | [GuS] has joined IRC ([GuS]!~gustavo@unaffiliated/gus/x-663402) | |
| 22:33 | toscalix has left IRC (toscalix!~toscalix@68.166.219.87.dynamic.jazztel.es, Remote host closed the connection) | |
| 22:43 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 240 seconds) | |
| 22:44 | khildin has left IRC (khildin!~khildin@ip-83-134-214-50.dsl.scarlet.be, Remote host closed the connection) | |
| 23:13 | dead_inside has left IRC (dead_inside!~dead_insi@76.75.3.174, Quit: Leaving...) | |
| 23:47 | markit has left IRC (markit!~marco@88-149-177-66.staticnet.ngi.it, ) | |