Main page
[00:34] artista-frustrad (n=artista_@201-25-168-216.ctame704.dsl.brasiltelecom.net.br) joined #ltsp.
[00:37] Egyptian[Home] (n=Egyptian@62.117.46.108) left #ltsp.
[00:53] artista-frustrad (n=artista_@201-25-168-216.ctame704.dsl.brasiltelecom.net.br) left irc: Read error: 110 (Connection timed out)
[01:10] artista-frustrad (n=artista_@201-25-168-216.ctame704.dsl.brasiltelecom.net.br) joined #ltsp.
[01:16] Kicer86 (n=kicer@host-5db0eeee.sileman.net.pl) joined #ltsp.
[01:30] artista_frustrad (n=artista_@201-25-168-216.ctame704.dsl.brasiltelecom.net.br) joined #ltsp.
[01:32] artista-frustrad (n=artista_@201-25-168-216.ctame704.dsl.brasiltelecom.net.br) left irc: Read error: 110 (Connection timed out)
[01:45] Kicer86 (n=kicer@host-5db0eeee.sileman.net.pl) left irc: Client Quit
[01:51] artista_frustrad (n=artista_@201-25-168-216.ctame704.dsl.brasiltelecom.net.br) left irc: Read error: 110 (Connection timed out)
[03:14] rhodan_ (n=quassel@146-179.2-85.cust.bluewin.ch) joined #ltsp.
[03:21] rhodan (n=quassel@137-243.3-85.cust.bluewin.ch) left irc: Read error: 60 (Operation timed out)
[03:39] alkisg1 (n=alkisg@ubuntu/member/alkisg) joined #ltsp.
[03:40] alkisg (n=alkisg@ubuntu/member/alkisg) left irc: Read error: 60 (Operation timed out)
[04:52] artista_frustrad (n=artista_@201-25-168-216.ctame704.dsl.brasiltelecom.net.br) joined #ltsp.
[05:11] artista-frustrad (n=artista_@201-25-168-216.ctame704.dsl.brasiltelecom.net.br) joined #ltsp.
[05:11] artista_frustrad (n=artista_@201-25-168-216.ctame704.dsl.brasiltelecom.net.br) left irc: Connection timed out
[05:19] mikkel (n=mikkel@84-238-113-66.u.parknet.dk) joined #ltsp.
[05:28] artista (n=artista_@201-25-168-216.ctame704.dsl.brasiltelecom.net.br) joined #ltsp.
[05:29] artista-frustrad (n=artista_@201-25-168-216.ctame704.dsl.brasiltelecom.net.br) left irc: Read error: 110 (Connection timed out)
[06:00] lucascoala (n=lucascoa@201-92-76-149.dsl.telesp.net.br) joined #ltsp.
[06:25] artista (n=artista_@201-25-168-216.ctame704.dsl.brasiltelecom.net.br) left irc: Nick collision from services.
[06:26] artista-frustrad (n=artista_@201-25-168-216.ctame704.dsl.brasiltelecom.net.br) joined #ltsp.
[06:34] Nick change: alkisg1 -> alkisg
[07:23] alkisg (n=alkisg@ubuntu/member/alkisg) left irc: Read error: 110 (Connection timed out)
[08:27] gentgeen__ (n=kevin@c-98-236-71-64.hsd1.pa.comcast.net) joined #ltsp.
[08:58] gentgeen__ (n=kevin@c-98-236-71-64.hsd1.pa.comcast.net) left irc: Remote closed the connection
[09:00] gentgeen__ (n=kevin@c-98-236-71-64.hsd1.pa.comcast.net) joined #ltsp.
[09:01] _gentgeen_ (n=kevin@c-98-236-71-64.hsd1.pa.comcast.net) left irc: "Leaving"
[09:28] sene (n=sene@unaffiliated/sene) left irc: Read error: 60 (Operation timed out)
[09:30] _gentgeen_ (n=kevin@c-98-236-71-64.hsd1.pa.comcast.net) joined #ltsp.
[09:40] alkisg (n=alkisg@ubuntu/member/alkisg) joined #ltsp.
[09:40] _gentgeen_ (n=kevin@c-98-236-71-64.hsd1.pa.comcast.net) left irc: Remote closed the connection
[09:42] sene (n=sene@unaffiliated/sene) joined #ltsp.
[09:43] vagrantc (n=vagrant@c-76-27-239-73.hsd1.or.comcast.net) joined #ltsp.
[09:44] _gentgeen_ (n=kevin@c-98-236-71-64.hsd1.pa.comcast.net) joined #ltsp.
[09:50] _gentgeen_ (n=kevin@c-98-236-71-64.hsd1.pa.comcast.net) left irc: Remote closed the connection
[10:16] rhodan_ (n=quassel@146-179.2-85.cust.bluewin.ch) left irc: Remote closed the connection
[10:18] rhodan (n=quassel@146-179.2-85.cust.bluewin.ch) joined #ltsp.
[10:19] pmatulis (n=peter@mail.papamike.ca) joined #ltsp.
[10:24] [vagrantc] stgraber: get a chance to test the new group handling?
[10:33] lucascoala (n=lucascoa@201-92-76-149.dsl.telesp.net.br) left irc: Read error: 104 (Connection reset by peer)
[10:37] mikkel (n=mikkel@84-238-113-66.u.parknet.dk) left irc: "Leaving"
[10:39] etyack (n=etyack@c-76-112-195-83.hsd1.mi.comcast.net) joined #ltsp.
[10:40] etyack (n=etyack@c-76-112-195-83.hsd1.mi.comcast.net) left irc: Remote closed the connection
[10:41] artista-frustrad (n=artista_@201-25-168-216.ctame704.dsl.brasiltelecom.net.br) left irc: Remote closed the connection
[10:41] etyack (n=quassel@c-76-112-195-83.hsd1.mi.comcast.net) joined #ltsp.
[10:43] etyack (n=quassel@c-76-112-195-83.hsd1.mi.comcast.net) left irc: Remote closed the connection
[10:49] [alkisg] vagrantc, I'd like to correct the IFS handling, but I'm in doubt about what of the following to use:
[10:49] [alkisg] (1) test "$oldifs" = "not set" && unset IFS || IFS="$oldifs"
[10:49] [alkisg] (2) if [ "$oldifs" = "not set" ]; then unset IFS; else IFS="$oldifs"; fi
[10:49] [alkisg] (3) the same `if` written in 4 separate lines
[10:49] [alkisg] I think I'd go for (2) but I'm not sure if it's acceptable by our CodingStyle...
[10:50] [vagrantc] we wrote the codingstyle down somewhere...
[10:51] [vagrantc] pfft. README_DEVELOPMENT_POLICY is an empty file.
[10:51] [vagrantc] alkisg: from what i recall, one-liners should be like the 1st one.
[10:52] [vagrantc] alkisg: if you use if [ ] ... it should be split on multiple lines.
[10:52] [alkisg] Yup.... it's just less readable than (2) :-/
[10:52] [vagrantc] alkisg: so 1 and 3 were acceptible.
[10:52] [alkisg] I'd go for 1 then, it's more "copy/paste-able"
[10:52] [vagrantc] alkisg: i think a full if statement is really hard to read on one line.
[10:53] [vagrantc] so it's a matter of personal preference.
[10:53] [alkisg] The whole IFS thing needs attention, so even in (3), the developers reading it would need to read about the {-} operator... so I don't mind that (1) looks a bit more cryptic...
[10:53] litlebuda (n=litle@169.191.108.93.rev.vodafone.pt) joined #ltsp.
[10:54] [alkisg] OK, I'll commit something based on (1).
[10:55] [vagrantc] alkisg: that doesn't use the {-} thing at all?
[10:55] [alkisg] vagrantc: all those cases start with: oldifs="${IFS-not set}"
[10:56] [alkisg] http://ltsp.pastebin.com/m59481063
[10:56] [vagrantc] we sure make extensive use of IFS ...
[10:57] [vagrantc] alkisg: ah, that was just the restore portion of the code...
[10:57] [alkisg] Yup
[10:57] [vagrantc] alkisg: so it'll be one line at the top, and one line at the bottom?
[10:57] [alkisg] Right
[10:57] [vagrantc] of a given block of code
[10:57] [vagrantc] that's about as close to good as we can get :)
[10:57] [alkisg] Unless of course if we use (3) :)
[10:58] [alkisg] OK, committing something with (1), and I'll send a mail to ltsp-developers talking about it, as it's not something obvious.
[10:59] [vagrantc] and woe to the fool who attempts nested IFS values.
[10:59] [alkisg] If it's inside a function, oldifs should be declared local
[10:59] [alkisg] If it's outside a function, well, woe :)
[11:00] [vagrantc] i think it's woe in either case.
[11:00] [vagrantc] it's just plain painful
[11:00] [alkisg] Maybe tr should be used instead of IFS in most cases...
[11:00] [alkisg] The performance hit wouldn't be so bad to justify all the possible side effects...
[11:01] [vagrantc] well, parsing /proc/mounts, /etc/group and /etc/passwd is actually so much more elegant with IFS
[11:02] [vagrantc] but we definitely should be cautious with over-use of IFS for that reason.
[11:02] [alkisg] parsing /proc/mounts doesn't need IFS
[11:02] [vagrantc] ah, true. it's the passwd/group stuff that makes it easier...
[11:02] [vagrantc] it's basically because shell has stupid handling of spaces.
[11:03] [alkisg] Right...
[11:03] [vagrantc] and that's because it was never intended to be used for such crazy things as we are doing... i'm guessing. :)
[11:06] [alkisg] I do think that we shouldn't bother with saving/restoring IFS at all, though. Just forcing it to ' \t\n' after any changes should be better than saving/restoring it...
[11:06] [alkisg] Anyway, commiting (1)...
[11:06] [vagrantc] alkisg: hmmm... good point.
[11:06] [vagrantc] alkisg: we could make a "use of IFS" policy.
[11:07] [vagrantc] alkisg: or simply unsetting it.
[11:07] [alkisg] vagrantc: I don't know if all the shells/systems behave well when unsetting it
[11:07] [alkisg] E.g. I _rely_ on IFS being ' \t\n' on some cases
[11:07] [vagrantc] alkisg: seems to work fine in bash and dash.
[11:07] [alkisg] If the default IFS on some shell is only ' ', then it'd break some parts of the code
[11:08] [vagrantc] alkisg: that isn't equivalent to the defaults?
[11:08] [vagrantc] ah, got it.
[11:08] [alkisg] E.g. var=$(echo $var) ==> consolidate spaces, tabs and enters to single spaces ==> doesn't work with IFS=' '
[11:09] [alkisg] Anyway, I'll commit (1), and if we want we make explicitly set IFS at the start of each script
[11:10] [alkisg] *may
[11:27] highvolt1ge (n=highvolt@196-210-194-71-wblv-esr-3.dynamic.isadsl.co.za) joined #ltsp.
[11:28] Appiah (n=appiah@ip69.hethane.riksnet.nu) left irc: Remote closed the connection
[11:36] highvolt2ge (n=highvolt@196-210-194-71-wblv-esr-3.dynamic.isadsl.co.za) joined #ltsp.
[11:39] highvoltage (n=highvolt@ubuntu/member/highvoltage) left irc: Read error: 110 (Connection timed out)
[11:45] waldo323 (n=waldo323@99-24-180-54.lightspeed.livnmi.sbcglobal.net) joined #ltsp.
[11:54] highvolt1ge (n=highvolt@196-210-194-71-wblv-esr-3.dynamic.isadsl.co.za) left irc: Read error: 110 (Connection timed out)
[11:58] waldo323 (n=waldo323@99-24-180-54.lightspeed.livnmi.sbcglobal.net) left irc: "Ex-Chat"
[12:20] [k-train] how does one tell what the xorg.conf file looks like of a ltsp-client workstation?
[12:23] [vagrantc] !release
[12:23] [ltspbot`] vagrantc: "release" :: please mention the linux distro and release you're using :)
[12:23] [vagrantc] k-train: ^^
[12:24] [k-train] wow.. i'm such a noob. what does ^^ mean...
[12:24] [vagrantc] k-train: read the previous line
[12:24] [highvolt2ge] k-train: look at the line above
[12:24] [stgraber] alkisg: hello
[12:24] [alkisg] hello stgraber
[12:25] [vagrantc] ideally, we could tell ltspbot to direct the comments at someone in particular... but until then... we're stuck with ^^
[12:25] [stgraber] alkisg: any reason why you didn't use that one-liner you posted yesterday instead of the one you explained on the ML ?
[12:25] sebas891 (n=sebas@201.255.36.155) left irc: Client Quit
[12:25] [stgraber] is that because the one you commited is easier to read or was there actual technical issue with the other ?
[12:26] [alkisg] stgraber: I prefered a one-liner, and the CodingStyle said we have to use "test" in one-liners
[12:26] [vagrantc] k-train: it's really helpful when you ask a question if we know the context ...so knowing what distro/releaes you're using helps us determine how to best answer your question.
[12:26] [alkisg] stgraber: ah, you mean the "eval" one?
[12:26] [highvolt2ge] stgraber: howdy
[12:26] [alkisg] The eval one wasn't a good solution because it has problems if IFS contains '
[12:27] [highvolt2ge] stgraber: did you get that lucid lxc guest working?
[12:27] [vagrantc] and for our next episode in "Adventures with IFS" ...
[12:27] [k-train] k... sorry. I installed ubuntu 9.10-ltsp a bit ago.
[12:27] [stgraber] highvolt2ge: hey, nope I haven't had the time to look at it, way too much stuff to do and still something like two days late in what I was supposed to do this week ...
[12:28] [k-train] And i have a bunch of old machines that have an intel 815 video chip set and the refresh ir real bad when there is movement on the screen
[12:28] [highvolt2ge] stgraber: ok no problem, I was just wondering
[12:28] [stgraber] highvolt2ge: first issue is that networking issue, then I suspect we have some /dev/pts & /proc issue as well
[12:28] [stgraber] alkisg: yep
[12:28] [stgraber] ah, ok
[12:28] [k-train] I looked at the ltsp manual and tried many options in the lts.conf file.
[12:28] [highvolt2ge] stgraber: ok, with that info I'll poke a bit with it tonight, maybe I'll get lucky
[12:29] [k-train] link x_video_ram, xserver=810, but nothing seems to help.
[12:29] [vagrantc] k-train: you might try "ltsp-localapps x-terminal-emulator" which should give you an xterm running on the local client
[12:29] [vagrantc] k-train: and then look in /var/run/ltsp-xorg.conf ...
[12:29] [k-train] thanks tons. i will try that.
[12:31] Nick change: highvolt2ge -> highvoltage
[12:36] [stgraber] I'm going to do a new upstream snapshot of ltsp-trunk, if testing goes well, I'll likely tag + release 5.1.99 today, any reason I shouldn't ?
[12:36] [alkisg] Yey!
[12:38] [vagrantc] it's probably about time.
[12:38] [vagrantc] hoping the group changes isn't borked.
[12:39] [stgraber] yeah, that's part of the testing I'll do
[12:40] [stgraber] alkisg: did you try the latest package in my PPA, does it boot faster ?
[12:40] [alkisg] stgraber: sorry, I didn't try it, I'm trying to finish my private ltsp plugins for teachers here to test as soon as 5.1.99 is out...
[12:42] Kicer86 (n=kicer@host-5db0eeee.sileman.net.pl) joined #ltsp.
[12:52] [k-train] vagrantc: thank you. I was able to see the ltsp-xorg.conf file on my client. So.. am i right to think that since the 'xserver-xorg-video-intel' package is installed (i tired installing it in the chroot environment for the clients and it said it already existed) that my problems could be solved by simply supplying a xorg.conf file for the client via the lts.conf files that contains the proper parameters for an i815 video chipset?
[12:53] [vagrantc] k-train: it's possible.
[12:54] [k-train] ok... well i'm off to see if my amateur linux self can complete such a task. Thanks again.
[12:55] [alkisg] k-train: what exactly do you see?
[12:55] [k-train] in the ltsp-xorg.conf file?
[12:55] [alkisg] If you login and change the resolution/refresh rate etc, do you still see the problem?
[12:55] [alkisg] No, on your screens...
[12:59] [k-train] well.. ultimately things look ok all the time.... minus the poor refresh rates... I can't adjust the display on the clients while they are running because my server has an nvidia graphics card w/ the proprietary drivers installed so when i try to do so it tells me the i have to run nvdia-xconfig
[12:59] [stgraber] ok, uploaded a new ltsp-trunk to my PPA, should take 30min or so to build
[12:59] [stgraber] I'll also do one for ldm-trunk
[12:59] [k-train] or maybe i'm expecting too much from the thin clients.
[13:01] [stgraber] ldm-trunk snapshot uploaded
[13:02] [alkisg] k-train: logon on a client, and run this: xrandr
[13:02] [alkisg] Then, upload the results to this site: http://ltsp.pastebin.com
[13:02] highvoltage (n=highvolt@ubuntu/member/highvoltage) left irc: Read error: 60 (Operation timed out)
[13:02] [alkisg] It'll give you a URL, paste it here so that we can see the output.
[13:04] [k-train] k. i will do that
[13:07] japerry (n=japerry@drupal.org/user/45640/view) joined #ltsp.
[13:09] highvoltage (n=highvolt@ubuntu/member/highvoltage) joined #ltsp.
[13:18] [k-train] alkisg: here it is. http://ltsp.pastebin.com/d28b319cf
[13:19] [alkisg] k-train: you can try different resolutions with:
[13:19] bobby_C (n=bobby@85-124-22-227.teleworker.xdsl-line.inode.at) joined #ltsp.
[13:19] [alkisg] xrandr --output default --mode 1440x900
[13:19] [alkisg] And see if they help...
[13:19] [k-train] ok. i will try that. thank you.
[13:19] [alkisg] If they do, you can make one of those modes the default.
[13:21] japerry (n=japerry@drupal.org/user/45640/view) left irc: Remote closed the connection
[13:22] japerry (n=japerry@drupal.org/user/45640/view) joined #ltsp.
[13:31] [k-train] alkisg: i tried as you suggested and it appears to have helped a bit. there is one application that "trails the mouse" worse that the others. Does this happen?
[13:31] [alkisg] I'm not really sure what you're seeing...
[13:31] [alkisg] I had a problem with the AC current in one of my labs, it messed with the monitors,
[13:31] [alkisg] so I was unable to use them in their native resolutions, and I had to lower them
[13:32] [alkisg] It had too much flickering and it got worse when someone moved the mouse
[13:32] Kicer86 (n=kicer@host-5db0eeee.sileman.net.pl) left irc: Client Quit
[13:33] [alkisg] If you find a resolution that is better and you want to use it, you can specify it in lts.conf.
[13:34] [k-train] ok. Thanks for the example. I guess i'm not sure what to expect since this is my first go with Linux terminal server stuff. hearing what other people have done helps me to determine if the hard ware is incorrectly setup, or if what i'm asking to be done can't be done. (applicaitons, resolutions, etc) Thanks for your time.
[13:35] [alkisg] np. If it's possible, try to also boot the terminals as normal clients, to see if there's any difference.
[13:35] [alkisg] (e.g. if they have >= 512 RAM)
[13:36] [k-train] ok. Thanks. So, in your experience, should the LTS client act the same, visually, as it would as a normal client?
[13:37] [alkisg] With intel clients, yes, because they don't require proprietary drivers.
[13:38] [k-train] Ok. Another quick question, does it matter the video device on the server?
[13:38] [k-train] Is one preferred over another?
[13:38] [alkisg] Yes, the proprietary nvidia/ati drivers shouldn't be installed on the server
[13:39] [alkisg] So you could either keep your nvidia, but uninstall the drivers, or you could use another card. Or you could keep using the proprietary drivers and risk some problems.
[13:39] [vagrantc] it's so ridiculous that drivers installed on the server would cause problems with thin clients.
[13:39] [vagrantc] poorly written code.
[13:39] [alkisg] In Ubuntu there's an effort to separate the proprietary opengl libs from the opensource ones
back next →
1 2
up
Generated by logs2html module for eggdrop v.2.3.4
Find latest version at http://sourceforge.net/projects/logs2html or http://shmupsik.osetia.org