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


Channel log from 12 February 2010   (all times are UTC)

00:26Selveste1__ has quit IRC
00:27Egyptian[Home] has quit IRC
00:32alkisg has joined #ltsp
00:34
<alkisg>
Καλημέρα
00:39Egyptian[Home] has joined #ltsp
01:08Selveste1__ has joined #ltsp
01:12klausade has joined #ltsp
01:14Selveste1__ has quit IRC
01:17Selveste1__ has joined #ltsp
01:55gnunux has joined #ltsp
01:55
<gnunux>
hi
02:02
<Appiah>
yo
02:06mikkel has joined #ltsp
02:07Selveste1__ has quit IRC
02:24Selveste1__ has joined #ltsp
02:38F-GT has quit IRC
02:51bassie has quit IRC
02:55F-GT has joined #ltsp
02:55pts has joined #ltsp
03:09alkisg has quit IRC
03:14Selveste1__ has quit IRC
03:51wim_ has joined #ltsp
03:52ogra has quit IRC
03:53ogra has joined #ltsp
03:55
<wim_>
04:00alexqwesa has quit IRC
04:01
<Appiah>
if you are sure its a matter of a missing module I'd suggest you try to include it
04:02frederickjh has joined #ltsp
04:03
<Appiah>
Do you got multiple nics on the thin client wim_ ?
04:05
if yes its a known bug
04:05alexqwesa has joined #ltsp
04:26frederickjh has quit IRC
04:29alkisg has joined #ltsp
04:29frederickjh has joined #ltsp
04:36johnny has quit IRC
04:39
<wim_>
no i don't have multiple nics in my thin client. I tested it with ubuntu 9.04 live cd, network worked out of the box. with debian 5.0.3 live cd, no network. How can I include this module?
04:40
<Appiah>
build it i'd guess
04:44
download the driver source for the NIC, compile it , include it
04:44
refeer to debian docs for that
04:45
if the network works on ubuntu maybe you could just make a ubuntu chroot for that client instead
04:47
<alkisg>
Or maybe you could install a newer kernel on the chroot...
04:47
<wim_>
is there somewhere more information how to include this module in the kernel, these are production servers and I don't want to mess up things
04:47
<Appiah>
is there no debian live with later kernel?
04:48
5.0.3 is from 10-01-25
04:49
<wim_>
ive got this from http://debian-live.alioth.debian.org/
04:57ogra has quit IRC
05:03Faithful has quit IRC
05:04ogra has joined #ltsp
05:05Selveste1__ has joined #ltsp
05:07avlis has joined #ltsp
05:09hersonls has joined #ltsp
05:13alkisg has quit IRC
05:18alkisg has joined #ltsp
05:39avlis has quit IRC
05:39bobby_C has joined #ltsp
05:43bobby_C has quit IRC
06:05primeministerp has quit IRC
06:07Selveste1__ has quit IRC
06:12bobby_C has joined #ltsp
06:19pmatulis has joined #ltsp
06:27scottmaccal has joined #ltsp
06:29vvinet has quit IRC
06:59alkisg has quit IRC
07:03Blinny has joined #ltsp
07:08cliebow has joined #ltsp
07:31mgariepy has joined #ltsp
07:38Selveste1__ has joined #ltsp
07:44shawnp0wers has joined #ltsp
07:49alkisg has joined #ltsp
07:51johnny has joined #ltsp
07:51vvinet has joined #ltsp
07:57alkisg has quit IRC
08:09akSeya has joined #ltsp
08:09
<akSeya>
hi there
08:11grantk has joined #ltsp
08:12Selveste1__ has quit IRC
08:16Selveste1__ has joined #ltsp
08:18pts has quit IRC
08:25Selveste1__ has quit IRC
08:27litlebuda has joined #ltsp
08:28Selveste1__ has joined #ltsp
08:50Selveste1__ has quit IRC
08:50Selveste1__ has joined #ltsp
08:53
<vbundi>
Mornin all
08:55
<sbalneav>
Morning all
08:58
<vbundi>
morning
08:58
<akSeya>
i have a little problem here.. my network already has a DHCP server which I don't have access... is there a way to set my LTSP server to get an IP from that server and give it to the machines? or, a way to my DHCP server answers only to clients that are trying to boot PXE and ignore other requests..
08:59
morning ;)
08:59
<sbalneav>
There are two ways to solve that.
09:00
1) Partition off your thin clients on a separate switch, with a separate ethernet card. So there's two ethernet cards in the ltsp server, one for your main connection, one to handle the clients.
09:01
then the dhcpd server on the ltsp box just serves the clients.
09:01
the second is to use dnsmasq
09:01
but I don't know how to do 2). Others do.
09:01reynolds has joined #ltsp
09:01
<sbalneav>
I don't use it myself, as I prefer partitioning the traffic for thin clients off on it's own subnet.
09:01
<akSeya>
will search for dnsmasq ;)
09:03
isn't there a "Dhcp proxy" thing?
09:03
<sbalneav>
that's what dnsmasq is
09:03
<reynolds>
Does anyone have an opinion about server processors? I am looking to buy a server for my school that will support 60+ clients occasionally using flash. I am debating between xeon and i7 processors.
09:04
<akSeya>
hum.. ok then :D
09:04etyack has joined #ltsp
09:04
<sep>
if you have 60 people occasionaly using flash "at the same time" you have a big problem
09:04
<sbalneav>
akSeya: https://help.ubuntu.com/community/UbuntuLTSP/ProxyDHCP
09:04
<sep>
if you have a user ocassionaly using flash you might live
09:05
<reynolds>
I can local-app flash for many of the clients, but want some overhead.
09:06
<akSeya>
sbalneav: damn!! that's what I was looking for!!!
09:06
thanks a lot!!!
09:07arnadelo has joined #ltsp
09:07jcastro has quit IRC
09:07arnadelo has quit IRC
09:08Gadi has joined #ltsp
09:18F-GT has quit IRC
09:21
<vbundi>
Gadi: after a fresh install yesterday my client is booting much faster for some reason, (haven't change ltspfs_entry) http://imagebin.org/84530
09:22
bootchart looks totally different too
09:23reynolds has quit IRC
09:24
<Gadi>
vbundi: interesting
09:24
I wonder if you had any issue with the drive IO to the drive that /opt/ltsp/images/ lives on
09:24* Gadi is on a drive IO kick because he has a failing hard drive at home
09:25
<Gadi>
which makes it quite evident how much 300kbps IO speeds can cripple a system
09:25
;)
09:25
<vbundi>
lol
09:26
<Gadi>
vbundi: and I can tell from that install that you don't even have some of the additional recent optimizations we have been making
09:26
<vbundi>
I hope they aren't failing, they raid 1 setup is 1 month old
09:26
Gadi: really? I added Stephens repository
09:26
<Gadi>
this is a VM, right?
09:26
<vbundi>
the server is a real server
09:27
<Gadi>
yeah, we have some extra stuff since stephane's last upload
09:27
<vbundi>
oh nice
09:27* Gadi is awaiting his next upload to his ppa
09:27
<Gadi>
ah real server
09:27
drives are local or NAS/NFS?
09:27
<vbundi>
local
09:27Selveste1__ has quit IRC
09:27
<Gadi>
good
09:27
was it like that before?
09:28
<vbundi>
yes
09:28
<Gadi>
ok - so that prolly wasn't it
09:28
<vbundi>
what IS different hough
09:28
*though
09:28
is the previous install, I installed server 9.10 x64 and installed ltsp manually
09:29
ie apt-get install ltsp-server-standalone etc
09:29
this time I used the Alternate CD "Install LTSP Server" option
09:29alkisg has joined #ltsp
09:29
<vbundi>
so maybe I was missing something
09:30jcastro has joined #ltsp
09:31
<Gadi>
interesting
09:33
<vbundi>
wow look at this.. was auto generated, obviously I did not do this http://pastebin.org/90683
09:34
that's my /var/lib/tftpboot/ltsp/i386/pxelinux.cfg/default
09:34F-GT has joined #ltsp
09:34
<Gadi>
huh - looks like there's more code that someone changed that needs cleaning up
09:34
:P
09:34
this time it wasnt me
09:34
:)
09:35
<vbundi>
apparently
09:35
<Gadi>
ok.... who's been messing with ltsp-update-kernels??? fess up....
09:35
;)
09:36
<vbundi>
I cleaned up the file... ran ltsp-update-kernels and it screw it up again
09:36
sorry it DIDNT screw it up again
09:36
<Gadi>
hmmm....
09:36
<alkisg>
Known bug
09:36
I've reported that a while bug, along with a small fix
09:37
But then it stuck in the "I'd prefer a total rewrite" idea :P
09:37
<Gadi>
hehe
09:37
<vbundi>
nice :)
09:37* Gadi cheers alkisg on to bzr commit
09:37
<alkisg>
The dns one? It was about time - I thought we had dhcp dns since 1-2 years, and we didn't! :)
09:38
<Gadi>
wow - ur starting to sound like ogra
09:38
<vbundi>
ok so running ltsp-update-image --arch i386 is doing it
09:38
<alkisg>
The bug: https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/504733
09:38
Heh! So in 2 years I'm going to be messing with ARMs? Omg...!
09:40
<vbundi>
alkisg: my install from a day ago did not do this
09:40litlebuda has quit IRC
09:41
<vbundi>
that setup was ubuntu server 9.10 with ltsp installed after... whereas this setup is alternate CD "Install LTSP Server" option (in case you didn't see when I posted that earlier)
09:42* alkisg looks at the logs...
09:44
<alkisg>
vbundi: about a year ago, vagrantc changed pxelinux.cfg/default to contain multiple lines instead of one
09:45
vbundi: since then, if someone uses a different port than 2000, pxelinux.cfg/default is not working correctly,
09:45
<vbundi>
ohhhh
09:45
<alkisg>
because the "add nbdport=xxx" code is dumb and adds it to all the lines, assuming that it still only contains one line
09:45
<vbundi>
so the reason mine is doing this now and it didn't before... is because I have an amd64 chroot now
09:45
<alkisg>
Because you have 2 chroots
09:45
<vbundi>
yes
09:45
<Gadi>
shouldn't ltsp-update-kernels read in the current ports from inetd.conf and use those? and if none exist, start at a base port and increment for each chroot?
09:46
<alkisg>
Gadi, sure, and it should even write it to $ROOT/etc/ltsp/update-kernels.conf for update-kernels to get it later on
09:46
(e.g. to create an .nbd image)
09:47
*nbi
09:47
<Gadi>
why?
09:47
what does the nbi have to do with the port number?
09:47
<alkisg>
It doesn't use pxelinux.cfg/default, so it doesn't have any (other) way of knowing the nbd port
09:47
<Gadi>
dhcpd.conf?
09:48
<alkisg>
It would be really nice, but we don't use it
09:48
<vbundi>
oo I've never noticed mksquashfs say it uses all cores
09:48
<alkisg>
(and it wouldn't work in my particular use case, as I'm using proxydhcp)
09:48
<Gadi>
we should really deprecate nbi
09:49
now that etherboot has PXE
09:49
<alkisg>
I think there are some TCs that have etherboot though, and are not easily flashable
09:49
<Gadi>
ah
09:49
<alkisg>
But it's broken in Karmic anyway :P
09:49
...and noone cared enough to fix it!
09:49
<Gadi>
speaks volumes
09:49
<alkisg>
Yup
09:50
<Gadi>
anyhow, if the limitation of etherboot is that it has to be on the base port
09:50
I don't think too many people would holler
09:50
<alkisg>
No, it just has the kernel parameters hard-coded
09:50wim_ has left #ltsp
09:50
<Gadi>
right
09:50
<alkisg>
Whereas pxelinux gets them on the fly, from tftp
09:51
<Gadi>
we used to pass dhcp options for etherboot
09:51
<alkisg>
Ah... you're right
09:51
I forgot about that
09:51
<Gadi>
I am sure dnsmasq supports them as well
09:51
<alkisg>
OK, that would work. Proxydhcp + etherboot + different port wouldn't work, but that's too rare to care about
09:51
<Gadi>
I would prefer not going too crazy to try and muck with the chroot for nbi's sake
09:52
<alkisg>
Why is notifying the chroot crazy/
09:52
?
09:52
<Gadi>
more to break
09:52
hard to test
09:52
no one cares
09:52
:)
09:52
<alkisg>
Nah, I think it's even more logical than the current code
09:53
Right now, update-kernels generates a pxelinux.cfg/default
09:53
and ltsp-update-kernels copies it to the tftpboot dir
09:53* Gadi thinks we should just have a server-side conf file with BASE_PORT=foo
09:53
<Gadi>
have it pull in the value
09:53
<alkisg>
That pxelinux.cfg/default is ****different**** than the one generated by ltsp-update-image!!!
09:53
<Gadi>
and increment
09:54
<alkisg>
Then ltsp-update-kernels should have to parse / sed a text file
09:54
<Gadi>
it does?
09:54
<alkisg>
It does, but it doesn't do a good job (and hence the bug)
09:54
Using configuration files would be much saner
09:54
<Gadi>
I didn't realize pxelinux.cfg/default is in the chroot
09:54
I thought just all the boot files were copied
09:55
<alkisg>
There are 2 different tools that mess with it, update-kernels generates it in the chroot, ltsp-update-kernels copies it to tftp, and ltsp-update-image seds through it to change the port
09:55
I think that's a mess, and using configuration files would be better
09:56
<Gadi>
++
09:57* Gadi thinks we should never copy pxelinux.cfg/default from chroot to server
09:57
<Gadi>
just modify whatever is existing
09:57
and if none exists, create
09:58
<alkisg>
About pxelinux, I agree, but there might be cases (powerpcs?) that would need binary files in the tftp, and those could only be build on the chroot
09:58
(like .nbi, which is also binary, and we copy it to the chroot)
09:58
<Gadi>
building binaries in chroot is one thing
09:58
copying pxelinux.cfg/default is another
09:58
<alkisg>
Right
09:58
<Gadi>
so, copy the pxelinux.0 and other stuff
09:58
just not the cfg
09:59
<alkisg>
I agree (I think I also filed a bug for that 2 years ago :D)
09:59
<Gadi>
and if someone has screwed up their own config, they can just remove it and run ltsp-update-kernels
10:00
<alkisg>
Right. And $ROOT/etc/ltsp/update-kernels.conf would contain any info necessary to build that file, e.g. BOOTPROMPT_OPTS (ltsp-build-client would generate that file)
10:00* Gadi always thinks of shaving little critters with a nail file when folks say "I filed a bug"
10:00
<Gadi>
is that wrong?
10:01
<alkisg>
Heh :)
10:01
Hey, 2 years ago I only had a few months of linux experience...
10:01
Filing bugs was the best I could do!
10:01* ogra hands alkisg a time machine
10:01
<ogra>
fix that !
10:02
<alkisg>
Yup, I'll do that. But in good time - now the fat clients need more love than it...
10:03
<johnny>
who let ogra out
10:03
sup ogra :)
10:03
<alkisg>
:D :D :D
10:03
<ogra>
johnny, busy week ... FF ahead
10:03
<johnny>
ah swell
10:03
ahead?
10:03
<ogra>
next week, yes
10:03
<johnny>
day?
10:03
<ogra>
(faeture freeze)
10:04
<johnny>
i know
10:04
<ogra>
thu i think
10:04
<johnny>
i don't think we can get gajim .14 in there before then :(
10:04
gajim finally went xdg and gained some jingle support
10:04
<ogra>
is it in main ?
10:04
<johnny>
we also removed a glade dependency and went noarch
10:05
i'm not actually sure..
10:05
<ogra>
i think universe stays open longer
10:05
<johnny>
never used it on ubuntu
10:05
but good to know
10:05
<ogra>
its just a bit stricter for main this time because we work towards LTS
10:05
<johnny>
yeah
10:05
well.. luckily you'll get pidgin in time
10:06
oh wait.. for pidgin it doesn't matter..
10:06
but gajim won't be able to use new facebook im in .13
10:06
and that might upset some poeple
10:06
<ogra>
just switch them to empathy
10:06
<johnny>
yeah right
10:06
empathy is a poor client
10:06
suck
10:07
you can't sent raw xmpp stanzas. it's almost useless for anything but the basics
10:07* ogra didnt use IM for a long time
10:07
<johnny>
no roster versioning either
10:07
<ogra>
switch them to IRC :)
10:07
<johnny>
yeah right
10:07
are you insane ogra
10:07
<ogra>
you know me, make a guess :)
10:07
<johnny>
lol
10:08
ogra, really.. empathy is pretty useless for me..
10:08
the design of telepathy makes me super sad
10:08
too lcd
10:08
<ogra>
lcd ?
10:08
<johnny>
lowest commmon denominator
10:08
<ogra>
ah
10:09
well, it will grow over time
10:09
<johnny>
except you can't even send raw xmpp stanzas :(
10:09
<ogra>
remember gstreamer ... it was useless for ages and everyone used mplayer ...
10:09
<johnny>
sure.. except you don't have to worry about what version people other than you have
10:09
unlike with telepathy
10:10
we can't do X together unless you do why
10:10
Y*
10:10
<ogra>
because its stil young
10:10
<johnny>
ogra, no.. it's just the initial desgin philosohy..
10:10
gstreamer design was great from the getgo.. even if it wasn't ready
10:10
that's the opposite..
10:10
from telepathy
10:10
the lcd philosophy pervades..
10:11
perhaps they had no idea xmpp was going to be so widespread by now
10:11
that's my only nice thing i can imagine about it
10:11
the process i mean..
10:12
<ogra>
well, someone will write an XMPP extension for tlepathy one day
10:12
<johnny>
obviously you don't understand then..
10:12
i'll be quiet about it in #ltsp then :)
10:12
/me goes back to working with terribly written php code
10:14
<Blinny>
Hey, me too!
10:14
(except it's my code)
10:15litlebuda has joined #ltsp
10:17plamengr has joined #ltsp
10:17shogunx has joined #ltsp
10:28gvy has joined #ltsp
10:28* gvy waves a hand
10:28
<gvy>
hi :)
10:31plamengr has left #ltsp
10:31vagrantc has joined #ltsp
10:31litlebuda has quit IRC
10:33gnunux has quit IRC
10:41shogunx has quit IRC
10:44
<vagrantc>
alkisg: nice job on the test if resolv.conf is writeable. it's so tempting to use "test -w" or "[ -w ]" but that behaves inconsistantly depending on the shell.
10:45
only real way to test that something is writeable is to attempt to write to it :)
10:45
<alkisg>
vagrantc: I did think of that, but I saw in "man sh" that it doesn't really return if it's writeable, it just returns if it's chmod +w... (useless on a read only file system)
10:46
<vagrantc>
alkisg: bash, dash and /usr/bin/test all behave differently, at the very least.
10:46
so you don't get consistant behavior
10:46
<alkisg>
Ugh. Thanks, I'll keep that in mind
10:47
<vagrantc>
in debian, i patch ltsp/ldm/ltspfs upstream to use /usr/bin/test in most cases.
10:47
<alkisg>
vagrantc: I keep thinking we need a separate config file though, in /var/run/ltsp/values-from-initramfs.conf
10:48
I.e. initramfs can write some stuff there, e.g. the hostname, and the initscripts can use them
10:48
To avoid duplicating code...
10:48
Something like ltsp_config, but one that won't be regenerated
10:49
<vagrantc>
alkisg: /var/cache would be a little better ... doing early stuff in /var/run gets overwritten early in the debian ltsp boot process, as it gets mounted with a tmpfs.
10:49
although that may be because i asked it to do so... :)
10:49
<alkisg>
Heh
10:50
Sure, any dir will do for me, I haven't read FHS good enough to object in anything... :D
10:50
<vagrantc>
i should drop that for ltsp 5.2, and handle it from the initramfs.
10:51
<ogra>
vagrantc, you dont move mount /var/run ?
10:51
<vagrantc>
using /var/cache actually makes a lot of sense... it's where you store data that could be regenerated if it had to be... which is exactly what we're doing. although it's supposed to be able to survive a reboot, which we obviously don't :)
10:52
ogra: no, at some point i just asked the init system to handle it as it was run much earlier in the process
10:52
<alkisg>
Wouldn't it be better if we moved stuff *away* from the initramfs, e.g. in a 00- initscript?
10:52
<vagrantc>
ogra: but i may move it back into LTSP's control
10:52
<alkisg>
(again, to avoid duplicating code...)
10:52
<vagrantc>
since i finally figured out i can do that from the initramfs
10:53
alkisg: well, the *code* is still in the root filesystem, it's just a hook in the initramfs that runs a chrooted binary.
10:53
alkisg: so someone could run that code from an init script, if it suited their distro better. i tried to be clever. :)
10:54jelly-bean has joined #ltsp
10:54
<ogra>
vagrantc, well, in ubuntu mountall does that but i think there is a big delta between ubuntu and debian mountall due to upstart now
10:54
<vagrantc>
ogra: right
10:55
<gvy>
(in the voice of shrek) vagrantc, you *are* clever :)
10:55
hi ogra
10:55
glad to see you all
10:56
<jelly-bean>
thin clients are getting this error while booting and i know its something to do with dhcp http://pastebin.com/d1554b436
10:56
because i just switched dhcp servers and this started. if i switch back to old dhcp server it works. i have compared the dhcpd.conf files and they are very close. i am not sure what is causing the difference
10:56
any ideas?
10:57
<alkisg>
jelly-bean: karmic?
10:57
<jelly-bean>
ya
10:58
<alkisg>
known bug, unfortunately the fix didn't make it for karmic
10:58
You need to modify udhcp, let me get you a link...
10:59jelly-bean has quit IRC
10:59
<alkisg>
http://bazaar.launchpad.net/%7Eltsp-upstream/ltsp/ltsp-trunk/download/1652/udhcp-20090830223050-2djgfmyowairbgwl-3/udhcp
10:59
Heh
11:01jelly-bean has joined #ltsp
11:01
<jelly-bean>
odd. i just forced the new dhcp to use the old dhcpd.conf and it works. maybe i can post the two config files for comparison. they look identical to me on the important bits
11:02
<alkisg>
http://bazaar.launchpad.net/%7Eltsp-upstream/ltsp/ltsp-trunk/download/1652/udhcp-20090830223050-2djgfmyowairbgwl-3/udhcp
11:02
Download this file
11:02
<jelly-bean>
what do i do with this bin
11:02
<alkisg>
Overwrite /opt/ltsp/i386/usr/share/initramfs-tools/scripts/init-premount/udhcp with it
11:02
Then, run:
11:02
sudo chroot /opt/ltsp/i386 update-initramfs -u
11:02
sudo ltsp-update-kernels
11:03
And it should fix your problem./
11:03
<gvy>
alkisg, a wiki faq page, eh?
11:03
<alkisg>
gvy, yeah, we should make one :)
11:03
<gvy>
probably a relnotes/errata one
11:13
<jelly-bean>
it worked! you are awesome alkisg
11:17
<alkisg>
yw
11:18shogunx has joined #ltsp
11:31
<Gadi>
vagrantc: ping
11:35etyack has quit IRC
11:35Gadi_eeepc has quit IRC
11:36indradg has joined #ltsp
11:36Gadi_eeepc has joined #ltsp
11:36* vagrantc thwacks Gadi with a pong paddle
11:36
<indradg>
hi is this the right channel to ask about ltsp-cluster?
11:37
<vagrantc>
indradg: stgraber's the one to ask about that
11:37
<Gadi>
vagrantc: was this construct simply to ignore files with extensions: egrep ^[0-9a-zA-Z_\-]*$
11:37
<knipwim>
11:37
<Gadi>
if so, I would prefer to just strip extensions
11:37
<knipwim>
wrong window
11:38
<Gadi>
using a shell primitive
11:38
<indradg>
vagrantc, thanks
11:38
<Gadi>
as these bootcharts reveal, the repetitive use of basename and egrep get costly in large doses
11:38
<indradg>
stgraber, ping
11:39
stgraber, are there F12 packages available for ltsp-cluster?
11:39
<johnny>
/me has never heard of them
11:40
i don't even know if anybody has ever tested it on fedora
11:41
<vagrantc>
Gadi: it's basically to comply with debian's run-parts binary, in a distro incompatible way.
11:41* ogra doubts it
11:42
<alkisg>
Gadi is on a speed-up-ltsp quest...
11:42
<ogra>
yay
11:42
<Gadi>
vagrantc: I would prefer to use ${foo%%.*}
11:42
<alkisg>
Gadi, but using basename is more readable, maybe we should make functions with the same names?
11:42
<Gadi>
pheh
11:42
<ogra>
Gadi, beat that ! http://people.canonical.com/~ogra/osiris-lucid-20100202-6.png
11:42
<vagrantc>
Gadi: that doesn't catch ~ as a backup extension
11:42
<Gadi>
learn shell
11:42
<indradg>
johnny, what is confusing to me is this -> "LTSP-Cluster is provided via LTSP plugins shipped with the official LTSP distribution" from the ltsp-cluster website
11:43
johnny, what *is* the official distro?
11:43
<vagrantc>
Gadi: or half a dozen others.
11:43
Gadi: i'd rather match what we actually want than figure out what we don't.
11:43
<indradg>
johnny, i can't locate anything recent on warren togami's blog :(
11:44
<Gadi>
and to what end?
11:44
why must we be compat with run-parts binary?
11:45
we are free to say: files in these dirs with the following extensions will not be executed
11:45sepski has joined #ltsp
11:45jelly-bean has left #ltsp
11:45sepski has quit IRC
11:45
<vagrantc>
Gadi: because it has a good reason for that pattern?
11:45
<alkisg>
Couldn't we use case instead of egrep?
11:46
<vagrantc>
Gadi: it's easier to define what's valid than it is to say what isn't.
11:46
<johnny>
indradg, send him an email
11:46
or however you can t otalk to himi
11:46
<vagrantc>
cleaner.
11:46
<johnny>
can to talk to him*
11:46
<vagrantc>
alkisg: well, it's hard to get the same matching.
11:46
alkisg: but if we can, that'd be great.
11:47
<alkisg>
vagrantc: I think we can also use egrep once for all files, instead of using it once for every file
11:47
I.e. egrep first, and then do a "for file... basename"
11:47
<vagrantc>
that would be a significant improvement...
11:49
<alkisg>
Erm, I think we can just use one sed for all the loop
11:49
No for / if / echo whatsoever
11:50* alkisg tries that...
11:50
<vagrantc>
it was originally written for ltsp-build-client, and then got moved into other areas ... so it wasn't written with optimization in mind.
11:50shogunx has quit IRC
11:51
<Gadi>
yeah - its just painful to see clients spend 20 seconds on basename|egrep
11:51
:P
11:51hersonls has quit IRC
11:51
<vagrantc>
Gadi: i hear ya.
11:52
<Gadi>
especially when we're mostly checking that we ourselves don't do anything stupid
11:52
:)
11:53
it's like opening a door and pausing every second to make absolutely sure you don't hit yourself in the face
11:55
<alkisg>
Heh, run_parts_list /usr/sbin needs a second on my core 2 duo!
11:56
Nice catch, Gadi
11:56
<Gadi>
also, we have the same kind of code in ldm-script
11:56
so, we should be sure to fix in both places
11:57
also, I think ldm-script needs an unset SCRIPTS in the beginning, tho I guess we haven't been burned by that yet
11:58
<stgraber>
indradg: hi
11:58
<Gadi>
ldm-script also has an extraneous for loop
11:58
<vagrantc>
oh, be careful
11:59cliebow has quit IRC
11:59cliebow has joined #ltsp
12:00
<stgraber>
indradg: no, we don't have any package for fedora and I don't think somebody is working on it. Mostly because we (as in Revolution Linux), only deploy Ubuntu ;)
12:00
indradg: but if someone wants to work on that, we'll for sure announce it on the website and make it available on Launchpad ;)
12:01
<alkisg>
Gadi, can you try this? find -L /usr/sbin -mindepth 1 -maxdepth 1 -type f $find_opts | sort -n | sed -n 's/.*\/[0-9a-zA-Z_\-]\+$/&/p'
12:01
<Gadi>
1 sec - I am going into a mtg
12:01
brb
12:01
<alkisg>
k
12:02
<vagrantc>
alkisg: compare that to ls /usr/sbin
12:04
<alkisg>
vagrantc, and?
12:04
<vagrantc>
what's the comparison?
12:05
<alkisg>
I compared it to run_parts_list, and it had the same output...
12:05
<vagrantc>
and the speed?
12:06
<alkisg>
0m0.024s vs 0m2.104s
12:06
<vagrantc>
heh
12:06
<alkisg>
100 times faster...
12:06
<vagrantc>
trivial!
12:06
<alkisg>
I'll make a visible difference!
12:07
<vagrantc>
alkisg: so, you found a way to do it with a single call to sed?
12:07
<alkisg>
Yeah, the one above
12:07
<vagrantc>
ah, missed that
12:07
<alkisg>
I think I can also write it without the -n negation, to be more readable, but it's also good this way
12:08
<vagrantc>
what's the -n do?
12:08
<alkisg>
"don't produce any output by default, unless /p is used on matches"
12:09
<vagrantc>
looks like a big improvement.
12:10
though i seem to recall reading something about incompatible sed implementations recently..
12:11
<alkisg>
Some gnu-isms are on the sed man page, but that line is simple enough to be compatible...
12:11
Let me check in #sed to make sure, (in a while - have something to do now...)
12:12
<vagrantc>
could also use sed -n 's,.*/[0-9a-zA-Z_\-]\+$,&,p' ?
12:12
<alkisg>
Yup
12:12
Or #, whatever's more readable
12:12
<vagrantc>
reduces the esacping needed
12:14
that seems like a significant improvement, though :)
12:14
<alkisg>
Go go Gadi!
12:15
<vagrantc>
alkisg: may as well commit it, no?
12:15
<alkisg>
vagrantc: gimme some time to see if it can be written a little better, and test...
12:16
<vagrantc>
no releasing 5.2 till we get that everybody, ok? :)
12:16
<alkisg>
:P
12:18shogunx has joined #ltsp
12:21
<alkisg>
OK, here it is: find -L /usr/sbin -mindepth 1 -maxdepth 1 -type f | sort -n | sed -n '/.*\/[0-9a-zA-Z_\-]\{1,\}$/p'
12:24
time run_parts_list /usr/bin > /tmp/2 ==> 14 secs, omg...
12:24
<vagrantc>
that's the original?
12:24
<alkisg>
Yes, the new one is 0m0.042s
12:24
<vagrantc>
astounding!
12:25
i've got a patch for ldm-script, too
12:25
<alkisg>
OK, commiting...
12:25
<vagrantc>
that's called quite a few times, too ...
12:27gvy has quit IRC
12:28
<vagrantc>
the great grep reclamation
12:28
<alkisg>
sed might be unreadable, but it's also unbeatable :)
12:32hersonls has joined #ltsp
12:33Selveste1__ has joined #ltsp
12:38litlebuda has joined #ltsp
12:39
<vagrantc>
alkisg: even got rid of the for loop :)
12:40
<alkisg>
I love the commits with more - than + :)
12:49
<indradg>
stgraber, sorry was afk
12:49
stgraber, so "official distro" should read as "Ubuntu" .. right?
12:50
<alkisg>
indradg: I think stgraber means "upstream" when he speaks of the official ltsp distribution...
12:51
I.e. the upstream tarballs, as opposed to the ubuntu .debs
12:52
I.e. "the code for ltsp-cluster is in upstream ltsp, it isn't an ubuntu-specific thing..."
12:53
<indradg>
stgraber, alkisg, so if one wants to play with the latest version of ltsp-cluster do one use Ubuntu 9.10 or a PPA repo or should I go back and RTFM more? =P
13:03etyack has joined #ltsp
13:04shawnp0wers has quit IRC
13:08alkisg has quit IRC
13:18loather-work has quit IRC
13:20alkisg has joined #ltsp
13:26litlebuda has quit IRC
13:27jcastro has quit IRC
13:28cliebow has quit IRC
13:28litlebuda has joined #ltsp
13:28cliebow has joined #ltsp
13:31litlebuda has quit IRC
13:36
<Gadi>
wow, I go off for one meeting and we've increased the boot time by two orders of magnitude? :)
13:36
alkisg, vagrantc: bravo
13:36
<vbundi>
sounds like you need to take longer lunch breaks ;P
13:36
<Gadi>
definitely
13:37
<vbundi>
hey question for ya...
13:37
<Gadi>
I feel like George Castanza
13:37
<vbundi>
haha
13:37* vagrantc suspects the overall boot speed won't increase by a fraction of an order of magnitude
13:37
<vbundi>
I've got my boot down to 2:05.. which is great.. but my chart is completely different now, I'm getting a very long string of ldm, basename, egrep - repeats a lot
13:37
<alkisg>
Gadi: even though the old run_parts_list needed 14 secs to process /usr/bin, and the new one needs only 0.04, I didn't notice any actual speed difference on boot...
13:38
Of course my /usr/bin has 1400 files :D
13:38
<johnny>
isn't that what they just fixed vbundi ?
13:38
<Gadi>
vbundi: thats what we just fixed
13:38
:)
13:38
<vbundi>
oh is that what you meant ;)
13:38
<johnny>
alkisg, you must be loosing it elsewhere?
13:39
alkisg, what's your boot chart like now?
13:39
<Gadi>
alkisg: you'll feel it on slower single-threaded CPU clients
13:39
<alkisg>
I'm trying to get a bootchart, but my clients hangs - out of memory :(
13:39
Gadi: the one I'm using is too slow :)
13:40
(128 ram / 400? or something like that CPU)
13:40
<Gadi>
alkisg: are you using all of the latest upstream fixes
13:40
<alkisg>
HP T1500 I think
13:40
<Gadi>
or just putting in a few here and there?
13:40
<alkisg>
No, not all of them, just that one change
13:40
+ whatever is on stgraber's ppa for lucid
13:40
<alincoln>
hey folks - LOCAL_APPS_EXTRAMOUNTS is broken upstream and has been probably since October. filed this bug with a patch to fix it: https://bugs.launchpad.net/ltsp/+bug/521147
13:41
<vagrantc>
alincoln: thanks!
13:41
<alincoln>
:)
13:42
<Gadi>
alincoln: the opts needed quoting?
13:42* Gadi wonders why homedir works
13:42
<alincoln>
Gadi: it's explained in the bug report
13:42
because IFS isn't set to , there
13:43hersonls has quit IRC
13:43
<vagrantc>
IFS, your wonderful and terrible freind.
13:43
<alincoln>
hehe
13:43
<Gadi>
clever
13:43
<vbundi>
so, my clients seem to work decently on a linux Desktop, and running the terminal server app from that desktop actually seems faster than running it in a screen_xx= setup..... is it all in my head or what
13:44
<Gadi>
vbundi: that could be
13:44
when rdesktop runs on the client, rdesktop and xorg compete for CPU cycles
13:45
<vbundi>
which would still be the case when running it from the linux desktop no?
13:45
<Gadi>
when rdesktop runs on the server, it uses CPU cycles and so xorg is free to go crazy on the client
13:45
<vbundi>
ohh
13:45
<Gadi>
rdesktop on server uses server CPU
13:46
<vbundi>
ohh I see so by running rdesktop in a screen its actually running it on the local client vs the server
13:46
<Gadi>
right
13:46
<vbundi>
that makes sense
13:46
<Gadi>
brb
13:48
<alkisg>
Ugh, if bootchart is installed, and update-initramfs / ltsp-update-kernels are called, but ltsp-update-image is *not* called, bootchart goes crazy and it consumes all the RAM :)
13:49
<vagrantc>
wow
13:49
<vbundi>
does yours actually give you a "run out of ram" message?
13:50
I'm wondering if that was happening to me.. my TC seemed to hang a few times on boot but is good now and nothing changed except for running update-image
13:50
but I didn't get any memory error
13:50
<alkisg>
My bootchart: http://imagebin.org/84572
13:51vagrantc has quit IRC
13:51
<alkisg>
vbundi: yeah, and it starts killing processes...
13:52
<vbundi>
wow your terminal kicks mines ass
13:52
where's it killing stuff though I don't see it
13:53
here's my fastest yet.... http://imagebin.org/84573 still quite a bit messier than yours
13:54vagrantc has joined #ltsp
13:54
<vbundi>
must be all those lucid changes...
13:56
alkisg: I don't see in your chart where it's killing stuff
13:56
<vagrantc>
alincoln: committed your patch :)
13:56
<alincoln>
vagrantc: thanks!
13:57* vagrantc rummages around for launchpad login creds.
13:57hersonls has joined #ltsp
13:59
<etyack>
what are people using as an alternative to adobe flash for watching youtube?
13:59reynolds has joined #ltsp
13:59
<vbundi>
I think swfdec is pretty good
13:59
<vagrantc>
there's some tricks to using vlc, i've heard
14:00
<alkisg>
vbundi: I updated the image - I couldn't get the chart otherwise...
14:00
etyack: youtube has an html5 option nowadays, so that might be better...
14:01Blinny has left #ltsp
14:01
<vbundi>
alkisg: yeah I was wondering how you got a chart if you ran out of memeory
14:01
brb rebooting
14:01vbundi has quit IRC
14:01
<etyack>
alkisg: tried it with chrome, but will it work with FF?
14:01
<alkisg>
Not currently. I don't know what will happen eventually...
14:01
But that would be the most stable option...
14:02
There's a totem youtube plugin. Very fast, a little unstable
14:02
There's a KDE app == youtube client - haven't tried it
14:02
<vagrantc>
options, options, options :)
14:02
<etyack>
the totem plugin would be transparent to the user
14:02
<alkisg>
No, you go to totem to search for youtube videos
14:02
With a closed browser...
14:02
<etyack>
ahh
14:03
<alkisg>
It's there on the default ubuntu install - I don't know about other distros
14:03
<etyack>
we need it to embed with the browser
14:03
<alkisg>
There's also a greasemonkey script that changes the youtube page on the fly to use vlc / mplayer etc
14:04
Works fine, but it breaks whenever the youtube page gets updated...
14:04
If it was on a PPA, and got frequent updates, and if we were able to install it for all users, that would be the best option currently - but it isn't, unfortunately...
14:05
!flash
14:05
<ltspbot>
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 the HQtube plugin. Install greasemonkey for firefox, and see http://userscripts.org/scripts/show/24999
14:05
<etyack>
ltspbot you rock!
14:05
<ltspbot>
etyack: Error: "you" is not a valid command.
14:07
<alincoln>
haha
14:07
<etyack>
thanks for the info
14:08
<alkisg>
Gadi: can't we combine all the amixer calls into one?
14:09
<vagrantc>
alkisg: on a rampage!
14:09
<alkisg>
:D
14:09* alkisg learned how to get bootcharts... beware!
14:11litlebuda has joined #ltsp
14:14vbundi has joined #ltsp
14:17
<Gadi>
alkisg: I am not sure if amixer can set more than one channel perl line
14:17
*per
14:17
but, it's worth looking into
14:17
<alkisg>
Gadi, I've never even seen it before, but the man page says "..." and I hope it means "more parameters" :D
14:18
<Gadi>
A simple mixer control must be specified. Only one device can be
14:18
controlled at a time.
14:18
but I suppose that means one device
14:18
not one channel
14:23
<alkisg>
Gadi, see the --stdin option
14:23
<Gadi>
alkisg: I think ur out of luck on that one - but I did add VOLUME_MANUAL=<bool> the other day that should help save some time on slower clients
14:24
<alkisg>
Read from stdin and execute the command on each line sequentially. When this option is given, the command in command-line arguments is ignored.
14:24
<Gadi>
so, you argue that one amixer with several ssets will be faster than several amixers
14:25
worth a try
14:27cliebow has quit IRC
14:29
<alkisg>
1000 calls => 0m6.538s vs 0m0.031s
14:29
It's a difference, but not a noticable one...
14:30
...as there won't be more than a dozen calls to amixer...
14:30
Anyway it's still an improvement if you have some time to spare on it
14:30
<vbundi>
on my client I see more than a dozen amixer calls in my bootchart
14:31
<alkisg>
Yeah, those could be reduced to just 2, but I don't think there'll be any noticable speed improvement.
14:31
<vbundi>
hmm
14:32etyack has quit IRC
14:32
<vbundi>
my client takes about 40 seconds doing amixer calls
14:32
<alkisg>
But it does other things along with that
14:33
<vbundi>
yeah
14:33
<vagrantc>
the flies will not notice shaving 100 hairs off of a camel.
14:33
<vbundi>
^ that's deep for a friday.
14:33
<johnny>
so.. where's the big win then..
14:34
any left?
14:34indradg is now known as idg|Zzzzz
14:35
<vagrantc>
i'm glad we've done a lot of these optimizations... and i suspect all of them added up will be noticeable... or at least measureable.
14:35
<vbundi>
vagrantc: unless there are only 101 hairs left on that camel ;)
14:35
<alkisg>
Gadi: http://alkisg.pastebin.com/d3a70c6ee
14:35Barbosa has joined #ltsp
14:35
<vbundi>
optimizations, while may not be as significant on newer faster hardware, make all the difference running the old stuff tho
14:35
<vagrantc>
the real danger is recursive loops that grow... that stuff is disasterous.
14:36
my main interest in thin clients is to support older hardware... or at least, that's how i got started.
14:36
<alkisg>
!vagrantc++
14:36
<johnny>
vagrantc, but what is called older hardware at freegeek is changing .. ?
14:37
<vagrantc>
johnny: yup. current mimimum spec is typically 1.8GHz.
14:37
<johnny>
whoa
14:37
<vagrantc>
make exceptions in some cases, but in general... it's crazy.
14:37
<johnny>
quite expansive .. i thoughti t was 800mhz ..
14:37
that was 2 years ago tho..
14:37
<vagrantc>
yup
14:38
<johnny>
800mhz is still pretty good as long as you stuff it with a 1gb of ram
14:43
<alkisg>
What's that S25ltsp-client- that I see on my bootchart?
14:45
Got it
14:45litlebuda has quit IRC
14:48
<vbundi>
<vagrantc> johnny: yup. current mimimum spec is typically 1.8GHz. --- For a terminal??
14:48
<knipwim>
my user won't login and i'm seeing the following error on the client
14:48
agetty[4109]: tty1: read: Inappropriate ioctl for device
14:48grantk has left #ltsp
14:48
<vagrantc>
vbundi: freegeek does computer re-use and recycling. the ones we re-use are 1.8+
14:48
<knipwim>
where should i look?
14:49
<vagrantc>
vbundi: http://freegeek.org for more info
14:51pmatulis has quit IRC
14:57
<vbundi>
damn I didn't think of doing that
14:58
they have lots of SFF 2.8GhZ P4 Dells on ebay for like 80 bucks a pop.
14:58
<Gadi>
alkisg: looks good to me
14:59
<alkisg>
Gadi: I could also help with sed if you want to speed things up...
15:00
Ah, no, only one sed there, nm
15:00
<Gadi>
alkisg: go ahead and commit a fix for that
15:00* Gadi wonders when stgraber plans to roll packages next
15:00
<alkisg>
Gadi, could you do it? I'm really unfamiliar with amixer...
15:00
<Gadi>
oh, sure I guess
15:01
I will need you to test
15:01
I am not in a good position to test atm
15:01
<alkisg>
ok, no problem there
15:05* alkisg also hopes that setting all the controls together might help with the feedback problem...
15:06
<Gadi>
pushed
15:06
nah - the feedback problem is because I adjust *all* volume channels by default
15:06otavio has quit IRC
15:06
<Gadi>
so, MIC and FRONT MIC get boosted to 90%
15:07
when nothing is specified
15:07
I should prolly have a lower default for MIC*
15:07
or *MIC*
15:08
<alkisg>
Gadi, so if I boot that TC with the ubuntu live cd, and see the volumes, and specify those in lts.conf, it won't get the problem?
15:08
<Gadi>
right
15:08
<alkisg>
ty
15:08* Gadi is not sure if the liveCD adjusts volumes or leaves it up to the driver
15:08
<Gadi>
since the liveCD ultimately boots a desktop that the user can use to adjust volumes
15:10shogunx has quit IRC
15:11
<alkisg>
Gadi, I think that whole loop should be rewritten as:
15:11
while read line; do .... done < LANG=C amixer -c0 scontents > amixer -c0 sset --stdin
15:11
...and replace all the amixer calls inside it with simple echo's
15:11
<johnny>
echo? why not just one echo?
15:12
use a var..
15:12
<Gadi>
alkisg: thats what I did
15:12
<johnny>
don't echo until you've assembled the whole thing..
15:12
<alkisg>
johnny, pipes are better than accumulating stuff in a var...
15:12
<johnny>
faster?
15:12
<alkisg>
E.g. imagine 2000 string concatenations
15:12
<johnny>
sounds slower..
15:13
<alkisg>
johnny: I've seen Delphi code that needed *days* to complete because of that problem
15:13
<johnny>
obviously pick your battles..
15:13
<alkisg>
...and, when rewritten properly, it took some msec
15:13
<johnny>
smalle stuff works better without pipes.. :)
15:13
larger stuff..
15:14
<alkisg>
The pipe will be there in any case
15:14
<Gadi>
alkisg: did you see my commit?
15:14
<alkisg>
Gadi, no - checking...
15:14
<Gadi>
quite an easy diff
15:18
<alkisg>
sudo cp client/initscripts/ltsp-init-common /opt/ltsp/i386/usr/share/ltsp/ltsp-init-common && sudo ltsp-update-image && reboot client, right?
15:18
<Gadi>
that should work
15:19
I just thought of something - we should be careful to make sure we don't go through the loop in cases where we don't echo anything
15:19
which would happen right now if you set VOLUME_MANUAL=True without setting any channels
15:20
or at least we should make sure that it exits gracefully
15:20
that should be something to test
15:21shogunx has joined #ltsp
15:26
<Gadi>
gotta run, guys
15:26Gadi has left #ltsp
15:26shogunx has quit IRC
15:29* alkisg doesn't get it. /usr/share/ltsp/init-client-common does have the modified code in the client, but the bootchart still contains multiple alsa calls?!
15:33vvinet has quit IRC
15:35
<vagrantc>
should also test it on older versions of amixer
15:38
<alkisg>
How can I do what bootchart does, i.e. log processes, on a test script, to see if amixer spawns processes itself?
15:38
<johnny>
replace amixer with a shell script
15:38
that's one way..
15:39
<alkisg>
Hmmm if amixer spawns $0, that won't work....
15:41litlebuda has joined #ltsp
15:42
<alkisg>
Argh... amixer.c doesn't seem to spawn anything... what gives?
15:42
<johnny>
are you using nfs? or nbd?
15:43
you might want to switch to nfs if you're doing all this live work..
15:44
<vbundi>
is there a case where nbd is better than nfs?
15:44
<johnny>
obviously
15:44
<vagrantc>
it's faster
15:44
<johnny>
otherwise we wouldn't default to it in ubuntu
15:44akSeya has quit IRC
15:44
<johnny>
vbundi, why would you imagine it would be default if it wasn't better????
15:44
<vbundi>
err for some reason I Was thinking nfs was the default
15:44
<johnny>
ah
15:44
<vbundi>
I am mixed up
15:45
<johnny>
nfs is better if you're changing stuff to test things
15:45* vagrantc has experienced many defaults that worsen things
15:45
<vagrantc>
NFS is the default on debian
15:45
until recently, the other options require too much futzing to get working
15:46
and even now, the approach ubuntu takes isn't very stable on debian.
15:47
stgraber: any new patches for nbd-proxy? i haven't had that working without reverting to the code from 5.1.99
15:47
<vbundi>
well I'm glad to say that my LTSP5 performance is now on par with my LTSP4 performance, minus the boot time being about a minute longer which is not a big deal for these guys
15:48
<johnny>
good!
15:48
<vbundi>
that being said, when I spoke to them it sounded like they are on board with upgrading the thin clients now anyways... lol
15:48
<johnny>
let's kill ltsp4 dead.. :)
15:49
<vagrantc>
we should poll ltsp-discuss about installations using ltsp4 ... and make them offers of "protection"
15:51
<alkisg>
What does ltsp4 offer? sound? usb sticks?
15:51
<vagrantc>
for the adventurous
15:51
<alkisg>
(more than X -query, that is...)
15:51
<vagrantc>
yes, it was possible. but not as well integrated.
15:52
coming from someone who only jumped on the muekow bandwagon as one of those new upstarts trying to change everything :)
15:52* alkisg thinks of trying ltsp4 for some 32mb clients :P :D
15:52
<alkisg>
(nah :D)
15:52* vagrantc adds alkisg to "The List"
15:54hersonls has quit IRC
15:55
<highvoltage>
zomg The List
15:55lucascoala has joined #ltsp
15:56
<alkisg>
Urm, ok. I changed the amixer call to "true", and I still have sound, and I still have those amixer processes on the bootchart
15:56
So... something else runs amixer :)
15:57
<stgraber>
vagrantc: current version is considered "stable" ;) I was waiting for highvoltage to do some VBox test to see what's wrong as alkisg reported it doesn't work in VBox
15:57
<vagrantc>
stgraber: ah, all my tests on qemu failed as well.
15:58
<alkisg>
speaking of which, highvoltage, did you do any tests?
15:58* alkisg has heard of a fellow teacher that had problems with nbd-proxy on a real client
16:00
<alkisg>
Ah, finally, saw it. There are two things that use amixer, and I was looking at the wrong one :)
16:00
Yeah, 20 secs ==> less that 1 sec
16:01
Good job
16:01mgariepy has quit IRC
16:01litlebuda has quit IRC
16:01
<johnny>
so.. when are you gonna have to start prodding upstream to make more gains alkisg ?
16:01
<vagrantc>
alkisg: that the while ... ; do ... ; done | amixer ?
16:02
<alkisg>
johnny: prodding ? (sorry haven't installed my dict yet on lucid :D)
16:02
vagrantc: yes
16:02
<johnny>
poking?
16:02
<alkisg>
But the 20 secs => 1 sec is not a real gain, as it doesn't really use CPU there
16:02
<johnny>
trying to convince them to do stuff that makes things faster :)
16:03
<alkisg>
Heh... Gadi put me into the whole thing - I was drinking my beer quietly, and he gave me all those crazy ideas about making things go faster :D
16:05
<vagrantc>
listening to Gadi_eeepc while drinking... dangerous stuff.
16:09
<staffencasa>
anyone using touchscreens on ltsp clients?
16:09
I'm stuck
16:10
<highvoltage>
alkisg: my week has been a comedy of errors. every time I wanted to get to that something else went wrong
16:10
<alkisg>
Ouch
16:11
<highvoltage>
oh yes my ltsp-build-client fails with "error: LTSP client installation ended abnormally"
16:11
<alkisg>
That's with a fat or a thin client?
16:11
<highvoltage>
thin
16:11
<alkisg>
Any errors above that?
16:11
<highvoltage>
nope
16:12
<alkisg>
Put debug on...
16:12
<staffencasa>
I have a fresh install of Ubuntu 9.10 Karmic, built the client, chrooted in and installed xserver-xorg-input-elographics, added a few lines to lts.conf, and nothing
16:12
<alkisg>
highvoltage: DEBUG=True ltsp-build-client ...
16:13
<highvoltage>
alkisg: yep, busy running...
16:16Appiah has quit IRC
16:16
<vbundi>
so these guys are willing to spend a bit of cache to get some better clients... I was thinking of some 2.8Ghz P4 Thick clients as they're about $100/ea and they only want 5
16:17
<staffencasa>
does anyone even use touchscreens or know how it should work?
16:17
<vbundi>
then they'll just take these HP Terminals and hand em down for basic stuff like employee email
16:18
staffencasa: you might be better off asking that kind of question in an xorg channel
16:18
<highvoltage>
alkisg: happens right after "DEBUG: Loading plugin: install: /usr/share/ltsps/plugins/ltsp-build-client/Ubuntu/025-locales
16:19
<alkisg>
highvoltage: ah, I know the problem
16:19
<vbundi>
staffencasa: I tried setting one up once and unless you're lucky I think it requires a bunch of manual xorg.conf editing
16:19
<alkisg>
highvoltage: It's the new libc or something like that, it uses .utf8 instead of .UTF-8, and that breaks everything... :(
16:19
<highvoltage>
alkisg: how odd
16:20
<alkisg>
highvoltage: so for schools here I'm setting LOCALE="el_GR.UTF-8", and that overrides the autodetected value, and it works
16:20
<vbundi>
so what do you guys think, is spending $100 on a 2.8Ghz thick client a good idea? Newer atom based clients are like $300+ and they don't wanna go that route
16:20
<alkisg>
But we should patch LTSP to cope with that...
16:21
(settings LOCALE ==> in ltsp-build-client.conf)
16:22
<staffencasa>
vbundi, is there a way to at least tell what modules are loaded on the client?
16:23
because at this point we aren't sure where the problem lies
16:23
<vbundi>
staffencasa: first get it working on an ubuntu desktop, plug your USB for your touchscreen in and check your logs like dmesg
16:24
<staffencasa>
it's a built-in serial screen, though :(
16:24
<alkisg>
highvoltage: it might also be a gdm problem. What do you get with `echo $LANG` in your server xorg, and what do you get in vt1?
16:25
<highvoltage>
alkisg: en_ZA.utf8
16:25
<vbundi>
staffencasa: yeah... good luck sorry I can't really help
16:25
<alkisg>
highvoltage: and, on vt1? (alt+ctrl+f1, login..)
16:26
<staffencasa>
k, thanks anyways
16:26
<highvoltage>
alkisg: same from a vt
16:26
<alkisg>
highvoltage: you don't get en_ZA.UTF-8 with caps?
16:27
<vbundi>
staffencasa: again I'd check with the xorg guys, getting a touchscreen to work is like getting a serial mouse to work, the serial data just has to be interpereted properly
16:27
<highvoltage>
alkisg: nope
16:27
<vbundi>
staffencasa: ie, not an ltsp thing
16:27
<alkisg>
highvoltage: ok, so it's not a gdm problem. :( OK let me give you a quick fix for 025-locales..
16:29loather-work has joined #ltsp
16:31
<alkisg>
# locale-gen can't handle LANG.utf8 locales, it needs LANG.UTF-8.
16:31
if [ "$LOCALE" != "${LOCALE%utf8}" ]
16:31
LOCALE="${LOCALE%utf8}UTF-8"
16:31
fi
16:31
highvoltage: right below if [ -z "$LOCALE" ]; then
16:31
LOCALE="$LANG"
16:31
fi
16:31
*below of
16:32
<staffencasa>
vbundi, k, I'm going to try and just install ubuntu on the client (bypass ltsp) and get the touchscreen to work there. I think this will help resolve this.
16:33
<alkisg>
highvoltage: sorry, it also needs a "then" :D
16:34
<vbundi>
staffencasa: yeah that's a good place to start, once you get it working it's just a matter of enabling the working configuration in your chroot
16:34the_fronny has joined #ltsp
16:34
<vbundi>
staffencasa: what kind/model of terminal is it?
16:35
<staffencasa>
the hard part's getting ubuntu on the machine. It's an old box with only a floppy (No CD) and no option to boot to usb in the bios. It's a PioneerPOS PXi
16:35
Celeron 566 :)
16:36
but I can ghost it
16:36
<alkisg>
staffencasa: how much ram?
16:36
<staffencasa>
i think it's 256, but it might be 128
16:36
I forget
16:36
<vbundi>
https://wiki.ubuntu.com/PXEInstall
16:36
staffencasa: ^
16:36
<the_fronny>
Anyone here have any experience with Acer Aspire Revo 1600s in LTSP5? Along the lines of video probing and network drivers.
16:37
<staffencasa>
I'm PXE Booting it from a floppy
16:37
<alkisg>
staffencasa: see the automation script there: https://wiki.ubuntu.com/LiveCDNetboot#line-75 - but your RAM is too little for the live cd...
16:37
You might need the text mode installer :-/
16:38
<highvoltage>
alkisg: great thanks
16:38
<alkisg>
highvoltage: if it works, tell me, so that I commit it...
16:40
<vbundi>
the_fronny: search google for "nvidia ION LTSP5" , peopleare doing it, but it might require some tweaking for video... some information here https://help.ubuntu.com/community/UbuntuLTSP/AtomIon
16:40
<the_fronny>
Thanks vbundi!
16:40loather-work has quit IRC
16:41
<vbundi>
the_fronny: yeah install vdpau in your chroot and play full 1080P video on a thin client.. lol
16:43
<the_fronny>
vibundi: Ha! That's the last thing my users need to know about...
16:45loather-work has joined #ltsp
16:47
<highvoltage>
alkisg: yep it went fine
16:50F-GT has quit IRC
16:56shogunx has joined #ltsp
17:07the_fronny has quit IRC
17:08F-GT has joined #ltsp
17:12alkisg has quit IRC
17:21loathsome has joined #ltsp
17:23loather-work has quit IRC
17:31bobby_C has quit IRC
17:42frederickjh has quit IRC
18:12panthera has quit IRC
18:13stgraber has quit IRC
18:15Lns has joined #ltsp
18:20panthera has joined #ltsp
18:23mikkel has quit IRC
18:39morfic has quit IRC
18:39morfic has joined #ltsp
18:42staffencasa has quit IRC
18:43Selveste1___ has joined #ltsp
18:44Selveste1__ has quit IRC
18:56shogunx has quit IRC
19:10shogunx has joined #ltsp
19:23Lns has quit IRC
20:26pmatulis has joined #ltsp
20:31lucascoala has quit IRC
20:35vagrantc has quit IRC
20:36lucascoala has joined #ltsp
21:20pmatulis has quit IRC
21:26litlebuda has joined #ltsp
21:31jammcq has joined #ltsp
21:43lucascoala has quit IRC
22:25litlebuda has quit IRC
23:01F-GT has quit IRC
23:10mushroomtwo has quit IRC
23:13idg|Zzzzz is now known as indradg
23:14mushroomblue has joined #ltsp
23:18F-GT has joined #ltsp
23:36mushroomblue has quit IRC