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


Channel log from 28 March 2012   (all times are UTC)

00:03shogunx has left IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com, Read error: No route to host)
00:04shogunx has joined IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com)
00:11rthomson has left IRC (rthomson!~rthomson@mars.pet.ubc.ca, Quit: Reached EOD)
00:15adrianorg has joined IRC (adrianorg!~adrianorg@177.18.170.194)
01:41alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Quit: Хана X'ам !!!)
01:56Parker955 is now known as Parker955_Away
01:57Parker955_Away is now known as Parker955
02:06irule has joined IRC (irule!~irule@189.199.30.249)
02:24adrianorg has left IRC (adrianorg!~adrianorg@177.18.170.194, Ping timeout: 240 seconds)
03:20Parker955 is now known as Parker955_Away
03:26alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
03:40kodez has joined IRC (kodez!~kodez@8ta-151-6-32.telkomadsl.co.za)
03:46cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 245 seconds)
04:25irule has left IRC (irule!~irule@189.199.30.249, Read error: No route to host)
04:46staffencasa has left IRC (staffencasa!~staffenca@128-193-148-207.oregonstate.edu, Ping timeout: 240 seconds)
04:47alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Ping timeout: 252 seconds)
04:56alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
05:00Trixboxer 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:28cyberorg 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:38bauerski 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:04shawnp0wers has left IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers, Ping timeout: 248 seconds)
06:05shawnp0wers has joined IRC (shawnp0wers!~spowers@71-13-74-18.static.aldl.mi.charter.com)
06:05shawnp0wers has joined IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers)
06:08cyberorg has left IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg, Ping timeout: 260 seconds)
06:12shawnp0wers has left IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers, Ping timeout: 265 seconds)
06:21shawnp0wers has joined IRC (shawnp0wers!~spowers@71-13-74-18.static.aldl.mi.charter.com)
06:21shawnp0wers has joined IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers)
06:51shawnp0wers has left IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers, Ping timeout: 260 seconds)
06:53shawnp0wers has joined IRC (shawnp0wers!~spowers@71-13-74-18.static.aldl.mi.charter.com)
06:53shawnp0wers has joined IRC (shawnp0wers!~spowers@linuxjournal/staff/shawnp0wers)
07:10DIoX|DaZ has left IRC (DIoX|DaZ!~KaKa@server.civicclub.lt, Ping timeout: 265 seconds)
07:10alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
07:11DIoX|DaZ has joined IRC (DIoX|DaZ!~KaKa@server.civicclub.lt)
07:22SmallR2002 has left IRC (SmallR2002!~quassel@c-98-253-173-240.hsd1.il.comcast.net, Ping timeout: 276 seconds)
07:24DIoX|DaZ has left IRC (DIoX|DaZ!~KaKa@server.civicclub.lt, Ping timeout: 260 seconds)
07:26DIoX|DaZ has joined IRC (DIoX|DaZ!~KaKa@server.civicclub.lt)
07:54dobber has joined IRC (dobber!~dobber@213.169.45.222)
07:59ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Excess Flood)
08:00ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de)
08:11alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
08:11cyberorg has joined IRC (cyberorg!~cyberorg@opensuse/member/Cyberorg)
08:20bobby_C has joined IRC (bobby_C!~bobby@chello080108221029.1.13.vie.surfer.at)
08:37sep has left IRC (sep!~sep@40.211.jostedal.no, Ping timeout: 260 seconds)
08:45ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Excess Flood)
08:47ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de)
09:13kodez has left IRC (kodez!~kodez@8ta-151-6-32.telkomadsl.co.za, Ping timeout: 240 seconds)
09:46Gremble has joined IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com)
10:05risca has left IRC (risca!~risca@wi-secure-2252.cc.umanitoba.ca, Ping timeout: 260 seconds)
10:09risca has joined IRC (risca!~risca@wi-secure-2252.cc.umanitoba.ca)
10:28toscalix has joined IRC (toscalix!~toscalix@68.166.219.87.dynamic.jazztel.es)
10:37alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
11:06shogunx has left IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com, Remote host closed the connection)
11:10shogunx has joined IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com)
11:11shogunx has left IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com, Client Quit)
11:11shogunx has joined IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com)
11:12shogunx has joined IRC (shogunx!~shogunx@rrcs-67-79-182-232.se.biz.rr.com)
11:14slinky_ has joined IRC (slinky_!~slinky@91.83.208.10)
11:14
<slinky_>
hi all
11:14slinky_ is now known as slin
11:14slin has joined IRC (slin!~slinky@frugalware/developer/slin)
11:17adrianorg 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:38khildin 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:45bobby_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:48Gremble 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:52risca 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:57alexqwesa has joined IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net)
12:13alkisg 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:44Gremble 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:48sep has joined IRC (sep!~sep@40.211.jostedal.no)
12:48zoobab 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:53bauerski has left IRC (bauerski!~witekb@frodo.psp.opole.pl, Quit: Leaving.)
12:54bauerski has joined IRC (bauerski!~witekb@frodo.psp.opole.pl)
12:58zoobab_ has joined IRC (zoobab_!zoobab@vic.ffii.org)
13:00bengoa 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:10bobby_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:23bauerski has left IRC (bauerski!~witekb@frodo.psp.opole.pl, Quit: Leaving.)
13:26ry has joined IRC (ry!~ry@static-71-183-64-28.nycmny.fios.verizon.net)
13:35risca has joined IRC (risca!~risca@wi-secure-2252.cc.umanitoba.ca)
13:43sep has left IRC (sep!~sep@40.211.jostedal.no, Ping timeout: 244 seconds)
13:54dead_inside has joined IRC (dead_inside!~dead_insi@76.75.3.174)
13:56Da-Geek has joined IRC (Da-Geek!~Da-Geek@94.236.7.190)
13:59Da-Geek has left IRC (Da-Geek!~Da-Geek@94.236.7.190, Client Quit)
14:04bobby_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:26risca 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:38ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Excess Flood)
14:38bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at)
14:39
<alkisg>
glxinfo => direct rendering: Yes
14:39ogra_ 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:49mcfloppy 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:58Mava 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:12TatankaT_ 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:15TatankaT 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:34staffencasa has joined IRC (staffencasa!~staffenca@128-193-148-207.oregonstate.edu)
15:36dobber has left IRC (dobber!~dobber@213.169.45.222, Remote host closed the connection)
15:40alexqwesa has left IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net, Ping timeout: 260 seconds)
15:41alexqwesa 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:46sep 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:58ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Excess Flood)
15:59ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de)
16:04Trixboxer 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:19neyder_ 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:39Gremble 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:51neyder_ 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:52slin 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:00risca 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:14mgariepy has left IRC (mgariepy!mgariepy@ubuntu/member/mgariepy, Remote host closed the connection)
17:14mgariepy 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:23risca has left IRC (risca!~risca@wi-secure-2901.cc.umanitoba.ca, Ping timeout: 272 seconds)
17:25monteslu_ is now known as monteslu
17:29komunista has joined IRC (komunista!~slavko@adsl-195-168-230-167.dynamic.nextra.sk)
17:37rthomson 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:28mikkel has joined IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk)
18:48Parker955_Away is now known as Parker955
18:57slin 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:26Parker955 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:34slin 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:39monteslu_ 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:43monteslu 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:50risca 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:10a23451a 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:22a12334a has joined IRC (a12334a!b85bdb19@gateway/web/freenode/ip.184.91.219.25)
20:23a23451a has left IRC (a23451a!b85bdb19@gateway/web/freenode/ip.184.91.219.25, Ping timeout: 245 seconds)
20:49markit has joined IRC (markit!~marco@88-149-177-66.staticnet.ngi.it)
20:58bengoa has left IRC (bengoa!~bengoa@2001:1291:229:2:216:cbff:feab:6cc9, Quit: Leaving.)
20:58alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.)
21:02mikkel has left IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk, Quit: Leaving)
21:08vagrantc 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:33mcfloppy 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:09risca has left IRC (risca!~risca@wi-secure-4931.cc.umanitoba.ca, Quit: Lämnar)
22:19a12334a has left IRC (a12334a!b85bdb19@gateway/web/freenode/ip.184.91.219.25, Quit: Page closed)
22:25komunista 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:33toscalix has left IRC (toscalix!~toscalix@68.166.219.87.dynamic.jazztel.es, Remote host closed the connection)
22:43bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 240 seconds)
22:44khildin has left IRC (khildin!~khildin@ip-83-134-214-50.dsl.scarlet.be, Remote host closed the connection)
23:13dead_inside has left IRC (dead_inside!~dead_insi@76.75.3.174, Quit: Leaving...)
23:47markit has left IRC (markit!~marco@88-149-177-66.staticnet.ngi.it, )