IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 24 January 2010 (all times are UTC)
| 00:59 | alkisg has joined #ltsp | |
| 01:34 | artista-frustrad has joined #ltsp | |
| 01:37 | Egyptian[Home] has left #ltsp | |
| 01:53 | artista-frustrad has quit IRC | |
| 02:10 | artista-frustrad has joined #ltsp | |
| 02:16 | Kicer86 has joined #ltsp | |
| 02:30 | artista_frustrad has joined #ltsp | |
| 02:32 | artista-frustrad has quit IRC | |
| 02:45 | Kicer86 has quit IRC | |
| 02:51 | artista_frustrad has quit IRC | |
| 04:14 | rhodan_ has joined #ltsp | |
| 04:21 | rhodan has quit IRC | |
| 04:39 | alkisg1 has joined #ltsp | |
| 04:40 | alkisg has quit IRC | |
| 05:52 | artista_frustrad has joined #ltsp | |
| 06:11 | artista-frustrad has joined #ltsp | |
| 06:11 | artista_frustrad has quit IRC | |
| 06:19 | mikkel has joined #ltsp | |
| 06:28 | artista has joined #ltsp | |
| 06:29 | artista-frustrad has quit IRC | |
| 07:00 | lucascoala has joined #ltsp | |
| 07:25 | artista has quit IRC | |
| 07:26 | artista-frustrad has joined #ltsp | |
| 07:34 | alkisg1 is now known as alkisg | |
| 08:23 | alkisg has quit IRC | |
| 09:27 | gentgeen__ has joined #ltsp | |
| 09:58 | gentgeen__ has quit IRC | |
| 10:00 | gentgeen__ has joined #ltsp | |
| 10:01 | _gentgeen_ has quit IRC | |
| 10:28 | sene has quit IRC | |
| 10:30 | _gentgeen_ has joined #ltsp | |
| 10:40 | alkisg has joined #ltsp | |
| 10:40 | _gentgeen_ has quit IRC | |
| 10:41 | sene has joined #ltsp | |
| 10:43 | vagrantc has joined #ltsp | |
| 10:44 | _gentgeen_ has joined #ltsp | |
| 10:50 | _gentgeen_ has quit IRC | |
| 11:16 | rhodan_ has quit IRC | |
| 11:18 | rhodan has joined #ltsp | |
| 11:19 | pmatulis has joined #ltsp | |
| 11:24 | <vagrantc> stgraber: get a chance to test the new group handling?
| |
| 11:33 | lucascoala has quit IRC | |
| 11:37 | mikkel has quit IRC | |
| 11:39 | etyack has joined #ltsp | |
| 11:41 | artista-frustrad has quit IRC | |
| 11:41 | etyack has joined #ltsp | |
| 11:49 | <alkisg> vagrantc, I'd like to correct the IFS handling, but I'm in doubt about what of the following to use:
| |
| 11:49 | (1) test "$oldifs" = "not set" && unset IFS || IFS="$oldifs"
| |
| 11:49 | (2) if [ "$oldifs" = "not set" ]; then unset IFS; else IFS="$oldifs"; fi
| |
| 11:49 | (3) the same `if` written in 4 separate lines
| |
| 11:49 | I think I'd go for (2) but I'm not sure if it's acceptable by our CodingStyle...
| |
| 11:50 | <vagrantc> we wrote the codingstyle down somewhere...
| |
| 11:51 | pfft. README_DEVELOPMENT_POLICY is an empty file.
| |
| 11:51 | alkisg: from what i recall, one-liners should be like the 1st one.
| |
| 11:51 | alkisg: if you use if [ ] ... it should be split on multiple lines.
| |
| 11:52 | <alkisg> Yup.... it's just less readable than (2) :-/
| |
| 11:52 | <vagrantc> alkisg: so 1 and 3 were acceptible.
| |
| 11:52 | <alkisg> I'd go for 1 then, it's more "copy/paste-able"
| |
| 11:52 | <vagrantc> alkisg: i think a full if statement is really hard to read on one line.
| |
| 11:52 | so it's a matter of personal preference.
| |
| 11: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...
| |
| 11:53 | litlebuda has joined #ltsp | |
| 11:54 | <alkisg> OK, I'll commit something based on (1).
| |
| 11:55 | <vagrantc> alkisg: that doesn't use the {-} thing at all?
| |
| 11:55 | <alkisg> vagrantc: all those cases start with: oldifs="${IFS-not set}"
| |
| 11:56 | http://ltsp.pastebin.com/m59481063
| |
| 11:56 | <vagrantc> we sure make extensive use of IFS ...
| |
| 11:57 | alkisg: ah, that was just the restore portion of the code...
| |
| 11:57 | <alkisg> Yup
| |
| 11:57 | <vagrantc> alkisg: so it'll be one line at the top, and one line at the bottom?
| |
| 11:57 | <alkisg> Right
| |
| 11:57 | <vagrantc> of a given block of code
| |
| 11:57 | that's about as close to good as we can get :)
| |
| 11:57 | <alkisg> Unless of course if we use (3) :)
| |
| 11:58 | OK, committing something with (1), and I'll send a mail to ltsp-developers talking about it, as it's not something obvious.
| |
| 11:59 | <vagrantc> and woe to the fool who attempts nested IFS values.
| |
| 11:59 | <alkisg> If it's inside a function, oldifs should be declared local
| |
| 11:59 | If it's outside a function, well, woe :)
| |
| 12:00 | <vagrantc> i think it's woe in either case.
| |
| 12:00 | it's just plain painful
| |
| 12:00 | <alkisg> Maybe tr should be used instead of IFS in most cases...
| |
| 12:00 | The performance hit wouldn't be so bad to justify all the possible side effects...
| |
| 12:01 | <vagrantc> well, parsing /proc/mounts, /etc/group and /etc/passwd is actually so much more elegant with IFS
| |
| 12:02 | but we definitely should be cautious with over-use of IFS for that reason.
| |
| 12:02 | <alkisg> parsing /proc/mounts doesn't need IFS
| |
| 12:02 | <vagrantc> ah, true. it's the passwd/group stuff that makes it easier...
| |
| 12:02 | it's basically because shell has stupid handling of spaces.
| |
| 12:03 | <alkisg> Right...
| |
| 12:03 | <vagrantc> and that's because it was never intended to be used for such crazy things as we are doing... i'm guessing. :)
| |
| 12:05 | <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...
| |
| 12:06 | Anyway, commiting (1)...
| |
| 12:06 | <vagrantc> alkisg: hmmm... good point.
| |
| 12:06 | alkisg: we could make a "use of IFS" policy.
| |
| 12:07 | alkisg: or simply unsetting it.
| |
| 12:07 | <alkisg> vagrantc: I don't know if all the shells/systems behave well when unsetting it
| |
| 12:07 | E.g. I _rely_ on IFS being ' \t\n' on some cases
| |
| 12:07 | <vagrantc> alkisg: seems to work fine in bash and dash.
| |
| 12:07 | <alkisg> If the default IFS on some shell is only ' ', then it'd break some parts of the code
| |
| 12:07 | <vagrantc> alkisg: that isn't equivalent to the defaults?
| |
| 12:08 | ah, got it.
| |
| 12:08 | <alkisg> E.g. var=$(echo $var) ==> consolidate spaces, tabs and enters to single spaces ==> doesn't work with IFS=' '
| |
| 12:09 | Anyway, I'll commit (1), and if we want we make explicitly set IFS at the start of each script
| |
| 12:09 | *may
| |
| 12:27 | highvolt1ge has joined #ltsp | |
| 12:28 | Appiah has quit IRC | |
| 12:36 | highvolt2ge has joined #ltsp | |
| 12:39 | highvoltage has quit IRC | |
| 12:45 | waldo323 has joined #ltsp | |
| 12:54 | highvolt1ge has quit IRC | |
| 12:58 | waldo323 has quit IRC | |
| 13:20 | <k-train> how does one tell what the xorg.conf file looks like of a ltsp-client workstation?
| |
| 13:23 | <vagrantc> !release
| |
| 13:23 | <ltspbot`> vagrantc: "release" :: please mention the linux distro and release you're using :)
| |
| 13:23 | <vagrantc> k-train: ^^
| |
| 13:23 | <k-train> wow.. i'm such a noob. what does ^^ mean...
| |
| 13:24 | <vagrantc> k-train: read the previous line
| |
| 13:24 | <highvolt2ge> k-train: look at the line above
| |
| 13:24 | <stgraber> alkisg: hello
| |
| 13:24 | <alkisg> hello stgraber
| |
| 13:25 | <vagrantc> ideally, we could tell ltspbot to direct the comments at someone in particular... but until then... we're stuck with ^^
| |
| 13: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 ?
| |
| 13:25 | sebas891 has quit IRC | |
| 13:25 | <stgraber> is that because the one you commited is easier to read or was there actual technical issue with the other ?
| |
| 13:25 | <alkisg> stgraber: I prefered a one-liner, and the CodingStyle said we have to use "test" in one-liners
| |
| 13: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.
| |
| 13:26 | <alkisg> stgraber: ah, you mean the "eval" one?
| |
| 13:26 | <highvolt2ge> stgraber: howdy
| |
| 13:26 | <alkisg> The eval one wasn't a good solution because it has problems if IFS contains '
| |
| 13:27 | <highvolt2ge> stgraber: did you get that lucid lxc guest working?
| |
| 13:27 | <vagrantc> and for our next episode in "Adventures with IFS" ...
| |
| 13:27 | <k-train> k... sorry. I installed ubuntu 9.10-ltsp a bit ago.
| |
| 13: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 ...
| |
| 13: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
| |
| 13:28 | <highvolt2ge> stgraber: ok no problem, I was just wondering
| |
| 13:28 | <stgraber> highvolt2ge: first issue is that networking issue, then I suspect we have some /dev/pts & /proc issue as well
| |
| 13:28 | alkisg: yep
| |
| 13:28 | ah, ok
| |
| 13:28 | <k-train> I looked at the ltsp manual and tried many options in the lts.conf file.
| |
| 13:28 | <highvolt2ge> stgraber: ok, with that info I'll poke a bit with it tonight, maybe I'll get lucky
| |
| 13:29 | <k-train> link x_video_ram, xserver=810, but nothing seems to help.
| |
| 13:29 | <vagrantc> k-train: you might try "ltsp-localapps x-terminal-emulator" which should give you an xterm running on the local client
| |
| 13:29 | k-train: and then look in /var/run/ltsp-xorg.conf ...
| |
| 13:29 | <k-train> thanks tons. i will try that.
| |
| 13:31 | highvolt2ge is now known as highvoltage | |
| 13: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 ?
| |
| 13:36 | <alkisg> Yey!
| |
| 13:38 | <vagrantc> it's probably about time.
| |
| 13:38 | hoping the group changes isn't borked.
| |
| 13:39 | <stgraber> yeah, that's part of the testing I'll do
| |
| 13:40 | alkisg: did you try the latest package in my PPA, does it boot faster ?
| |
| 13: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...
| |
| 13:42 | Kicer86 has joined #ltsp | |
| 13: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?
| |
| 13:53 | <vagrantc> k-train: it's possible.
| |
| 13:54 | <k-train> ok... well i'm off to see if my amateur linux self can complete such a task. Thanks again.
| |
| 13:55 | <alkisg> k-train: what exactly do you see?
| |
| 13:55 | <k-train> in the ltsp-xorg.conf file?
| |
| 13:55 | <alkisg> If you login and change the resolution/refresh rate etc, do you still see the problem?
| |
| 13:55 | No, on your screens...
| |
| 13: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
| |
| 13:59 | <stgraber> ok, uploaded a new ltsp-trunk to my PPA, should take 30min or so to build
| |
| 13:59 | I'll also do one for ldm-trunk
| |
| 13:59 | <k-train> or maybe i'm expecting too much from the thin clients.
| |
| 14:01 | <stgraber> ldm-trunk snapshot uploaded
| |
| 14:02 | <alkisg> k-train: logon on a client, and run this: xrandr
| |
| 14:02 | Then, upload the results to this site: http://ltsp.pastebin.com
| |
| 14:02 | highvoltage has quit IRC | |
| 14:02 | <alkisg> It'll give you a URL, paste it here so that we can see the output.
| |
| 14:04 | <k-train> k. i will do that
| |
| 14:07 | japerry has joined #ltsp | |
| 14:09 | highvoltage has joined #ltsp | |
| 14:18 | <k-train> alkisg: here it is. http://ltsp.pastebin.com/d28b319cf
| |
| 14:19 | <alkisg> k-train: you can try different resolutions with:
| |
| 14:19 | bobby_C has joined #ltsp | |
| 14:19 | <alkisg> xrandr --output default --mode 1440x900
| |
| 14:19 | And see if they help...
| |
| 14:19 | <k-train> ok. i will try that. thank you.
| |
| 14:19 | <alkisg> If they do, you can make one of those modes the default.
| |
| 14:21 | japerry has quit IRC | |
| 14:21 | japerry has joined #ltsp | |
| 14:30 | <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?
| |
| 14:31 | <alkisg> I'm not really sure what you're seeing...
| |
| 14:31 | I had a problem with the AC current in one of my labs, it messed with the monitors,
| |
| 14:31 | so I was unable to use them in their native resolutions, and I had to lower them
| |
| 14:32 | It had too much flickering and it got worse when someone moved the mouse
| |
| 14:32 | Kicer86 has quit IRC | |
| 14:32 | <alkisg> If you find a resolution that is better and you want to use it, you can specify it in lts.conf.
| |
| 14: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.
| |
| 14:35 | <alkisg> np. If it's possible, try to also boot the terminals as normal clients, to see if there's any difference.
| |
| 14:35 | (e.g. if they have >= 512 RAM)
| |
| 14:36 | <k-train> ok. Thanks. So, in your experience, should the LTS client act the same, visually, as it would as a normal client?
| |
| 14:37 | <alkisg> With intel clients, yes, because they don't require proprietary drivers.
| |
| 14:38 | <k-train> Ok. Another quick question, does it matter the video device on the server?
| |
| 14:38 | Is one preferred over another?
| |
| 14:38 | <alkisg> Yes, the proprietary nvidia/ati drivers shouldn't be installed on the server
| |
| 14:39 | 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.
| |
| 14:39 | <vagrantc> it's so ridiculous that drivers installed on the server would cause problems with thin clients.
| |
| 14:39 | poorly written code.
| |
| 14:39 | <alkisg> In Ubuntu there's an effort to separate the proprietary opengl libs from the opensource ones
| |
| 14:40 | The end result will be that ALL drivers can be installed simultaneously
| |
| 14:40 | Even nvidia-96 with nvidia-173 will be able to coexist, and of course only the right one will be used
| |
| 14:41 | If that actually happens, we'll be able to install all drivers to the ltsp chroot, and all clients would work automatically either with the open source or the proprietary drivers... that'd be cool.
| |
| 14:42 | <k-train> I can follow the last statement. :-) The others I kinda get the idea but don't understand details.
| |
| 14:44 | <vagrantc> still doesn't make sense why the $proprietary_driver code wouldn't ask the X.org server which driver it's actually using... instead of assuming it based on weather a certain set of files are installed...
| |
| 14:45 | <alkisg> I think the problem is that e.g. nvidia needs to ship its own, closed source opengl libs, and puts them in the same place where the opensource libs are, overwriting them
| |
| 14:45 | It should use a separate place for its proprietary libs, I think that's what they're trying to do, maybe with dpkg-divert, not sure...
| |
| 14:46 | And update-alternatives will point to the right lib, determined by some init script...
| |
| 14:46 | <vagrantc> "we can do whatever we want to your system"isms.
| |
| 14:47 | <alkisg> Right, it sucks :(
| |
| 14:51 | <k-train> Thanks for the great input guys. I'm off to play with my kids. I'll chat with you guys later.
| |
| 14:51 | <alkisg> Bye
| |
| 14:52 | k-train has left #ltsp | |
| 14:59 | Faithful1 has quit IRC | |
| 15:07 | <vagrantc> hrm.
| |
| 15:08 | stgraber, alkisg: looks like my add_mirrors changes are broken.
| |
| 15:08 | <alkisg> Whoops. How so?
| |
| 15:08 | <vagrantc> or did they work for y'all, and i botched my packaging?
| |
| 15:08 | * alkisg hasn't tried them | |
| 15:12 | <alkisg> We should create a test case, i.e. all the possible different calls to add_mirrors :)
| |
| 15:12 | <vagrantc> stupid typo.
| |
| 15:13 | <alkisg> btw, " if [ -z "$mirror" ] || [ "$mirror" = "none" ]; then" ==> I don't think [ -z "$mirror" ] is needed...
| |
| 15:14 | <vagrantc> alkisg: it's possible.
| |
| 15:14 | alkisg: i think i half-way converted to a different approach at some point and didn't finish it
| |
| 15:14 | <alkisg> Ehm sorry no it's needed if a line is empty
| |
| 15:16 | <vagrantc> stgraber: so there's definitely a bug in ltsp-build-client that will break...
| |
| 15:17 | <alkisg> file:///*) dir=$(echo "$mirror" | sed -e 's,^file://,,g') ==> can be written simplier as ==> file:///*) dir=${mirror#file://}
| |
| 15:17 | <vagrantc> pushing fix now
| |
| 15:17 | <stgraber> vagrantc: ok, I'll re-snapshot ltsp-trunk then ;)
| |
| 15:17 | <vagrantc> alkisg: more compact. don't know if i'd call it simpler :)
| |
| 15:17 | stgraber: just pushed the fix
| |
| 15:18 | it's amazing what happens when you actually fully test code.
| |
| 15:21 | <stgraber> I guess 5.1.99 will probably be our most tested release ;)
| |
| 15:21 | looking at the number of fix and optimization that went in
| |
| 15:22 | <alkisg> And 5.2 will be rock stable :)
| |
| 15:25 | <stgraber> then we can start breaking everything again ;)
| |
| 15:30 | <vagrantc> heh
| |
| 15:33 | vagrantc has quit IRC | |
| 15:34 | rjune has joined #ltsp | |
| 15:45 | bobby_C has quit IRC | |
| 15:45 | <stgraber> looks like the PPA builders are a bit overloaded, will take a while before we have ldm and ltsp built (unless you want them for amd64 as these are already built)
| |
| 15:45 | <alkisg> stgraber: would it be possible to reduce tftpd-hpa to recommends? It'll still be installed, but if someone wants to use dnsmasq, he'll be able to remove it...
| |
| 15:46 | (e.g. I'll be able to make my sch-scripts package depend on ltsp-server and dnsmasq and confict with tftpd-hpa)
| |
| 15:48 | <stgraber> ok, that should happen with the next build (so either another rebuild or with 5.1.99)
| |
| 15:49 | <alkisg> Thank you
| |
| 15:49 | <stgraber> btw, any idea why we depend on openssh-client | ssh on the server ?
| |
| 15:49 | I don't think we ever use the ssh client in ltsp-server ...
| |
| 15:49 | <alkisg> ssh-keygen?
| |
| 15:50 | openssh-client: /usr/bin/ssh-keygen
| |
| 15:50 | <stgraber> don't we simply copy the keys over from the server if they exist ?
| |
| 15:50 | <alkisg> server/plugins/ltsp-build-client/ALTLinux/010-ssh-keys: ssh-keygen -f "$ROOT"/etc/openssh/ssh_host_rsa_key -t rsa -C '' -N '' >&2
| |
| 15:50 | Hmmm...
| |
| 15:51 | <stgraber> well, that's ALTLinux ;)
| |
| 15:52 | <alkisg> Right, I don't see anything else that relates to ssh client in the sources...
| |
| 15:53 | BTW, openssh-server depends on the client, so we could safely remove it in any case :)
| |
| 15:53 | kaos01 has joined #ltsp | |
| 15:56 | Faithful has joined #ltsp | |
| 15:58 | alkisg has quit IRC | |
| 16:31 | Appiah has joined #ltsp | |
| 16:31 | vagrantc has joined #ltsp | |
| 16:51 | johnny has left #ltsp | |
| 17:02 | <rjune> ogra, you around?
| |
| 17:37 | pmatulis has quit IRC | |
| 17:48 | <kaos01> im assuming root in the chroot doesnt correspond to /root on the client ? As I dont see roots ssh keys
| |
| 17:50 | johnny has joined #ltsp | |
| 17:57 | <vagrantc> kaos01: correct.
| |
| 17:57 | kaos01: /opt/ltsp/i386 on the server corresponse to / on the thin client.
| |
| 17:57 | typically
| |
| 17:57 | sort of
| |
| 17:57 | <kaos01> i made /opt/ltsp/i386/root/.ssh but cant see it in /root/ on client
| |
| 17:58 | <vagrantc> !release
| |
| 17:58 | <ltspbot`> vagrantc: "release" :: please mention the linux distro and release you're using :)
| |
| 17:58 | <vagrantc> kaos01: ^^
| |
| 17:58 | <kaos01> fedora 12
| |
| 17:58 | <vagrantc> is it using NFS or NBD?
| |
| 17:58 | <kaos01> NBD
| |
| 18:00 | <vagrantc> kaos01: and you rebuilt the NBD image?
| |
| 18:00 | <kaos01> i believe so, but i should prob test it again before speeking :)
| |
| 18:00 | * vagrantc isn't too familar with fedora | |
| 18:01 | <kaos01> alos it seems my usb is mounted as sdb and not sdb1
| |
| 18:01 | its not mounting the partition
| |
| 18:13 | johnny has quit IRC | |
| 18:32 | <kaos01> yeap i cant see /root/.ssh
| |
| 18:33 | using NFS or NBD
| |
| 19:01 | pmatulis has joined #ltsp | |
| 19:13 | litlebuda has quit IRC | |
| 19:16 | johnny has joined #ltsp | |
| 19:23 | <vagrantc> hey, i stumbled upon something to minimize the risk to certain processes when the out of memory killer goes on a rampage...
| |
| 19:23 | http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=562884#34
| |
| 19:25 | <stgraber> yep, I use that to protect dbus and some ltsp-cluster daemons on my application servers
| |
| 19:25 | <vagrantc> maybe worth doing that by default for some things in general?
| |
| 19:26 | instead of/in addition to X_RAMPERC
| |
| 19:28 | <stgraber> we could protect X though it might already do some magic to avoid getting oomkilled
| |
| 19:28 | <vagrantc> it sure didn't used to do any magic
| |
| 19:28 | and was a big target, taking up so much memory
| |
| 19:30 | <stgraber> hmm, it doesn't seem to be protected against oomkills, though IIRC the oom-killer avoids processes with many children which is often the case for X and instead kills processes using a large amount of ram and without children (dbus for example)
| |
| 19:30 | I remember reading the exact logic it uses to determine what to kill
| |
| 19:31 | though protecting X is probably a very good idea in all cases and can easily be done from the xinittrc
| |
| 19:34 | <vagrantc> stgraber: X doesn't typically have many subprocesses in ltsp's case
| |
| 19:35 | er, children
| |
| 20:09 | _gentgeen_ has joined #ltsp | |
| 20:22 | johnny has left #ltsp | |
| 20:25 | vagrantc has quit IRC | |
| 20:42 | sene has quit IRC | |
| 20:46 | pmatulis has quit IRC | |
| 21:01 | etyack has joined #ltsp | |
| 21:04 | alexqwesa has quit IRC | |
| 21:06 | etyack has joined #ltsp | |
| 21:08 | etyack has joined #ltsp | |
| 21:11 | alexqwesa has joined #ltsp | |
| 21:19 | <sbalneav> Evening all
| |
| 21:25 | johnny has joined #ltsp | |
| 21:41 | rjune has quit IRC | |
| 22:00 | etyack has quit IRC | |
| 22:09 | <stgraber> for these interested in the new ltsp-cluster web interface: https://ltsp-control01.stgraber.org/loadbalancer/overview
| |
| 22:09 | feel free to play with the UI, it's a test database
| |
| 22:24 | <sbalneav> Ooooh
| |
| 22:24 | all web-2.0-ey drag-and-dropy
| |
| 22:24 | Slick
| |
| 22:26 | <stgraber> yep ;)
| |
| 22:26 | quite a change from our old one ;)
| |
| 22:27 | (which was more like web 0.1 ;))
| |
| 23:24 | <johnny> stgraber, now.. if only i could control my whole system with that :)
| |
| 23:24 | non ltsp..
| |
| 23:28 | alkisg has joined #ltsp | |
| 23:59 | mikkel has joined #ltsp | |