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


Channel log from 18 September 2010   (all times are UTC)

00:01MorningSon has quit IRC
00:22johnny has joined #ltsp
00:59poff has joined #ltsp
01:31poff has quit IRC
01:32poff has joined #ltsp
02:02alkisg has joined #ltsp
02:04poff has quit IRC
02:04poff has joined #ltsp
02:18poff has quit IRC
03:49alkisg has quit IRC
03:50alkisg has joined #ltsp
03:53alkisg has quit IRC
04:01alkisg has joined #ltsp
04:04cyberorg has joined #ltsp
05:16Kicer86 has joined #ltsp
06:06artista_frustrad has joined #ltsp
06:56alkisg has quit IRC
07:11pmatulis has joined #ltsp
07:51alkisg has joined #ltsp
07:58Kicer86 has quit IRC
08:26ogra_cmpc has quit IRC
08:30ogra_cmpc has joined #ltsp
08:39markit has joined #ltsp
08:41
<markit>
hi, a clarification please
08:41
if I setup, for instance, the power saving features/params when I'm logged in a thin client
08:41
am I acting against server setup or thin client one?
08:41
<alkisg>
The programs are running on the server, so any changes that you do are server settings
08:42
...with the exception of any X-related settings, because the X server is running on the client
08:42MorningSon has joined #ltsp
08:43
<markit>
alkisg: mmm so makes not sense try to prevent thin client to turn off screen after some minutes of inactivity using the KDE settings, right?
08:43
how on earth can be done then?
08:43
<alkisg>
X can turn the screen off
08:43
And X runs locally
08:43
<markit>
so I should hack xorg.conf?
08:43
<alkisg>
If KDE asks X to turn the screen off, then sure, it makes sense
08:44
No, I'm saying that it might just work, depending on the tools used
08:44
bbl
08:44
<markit>
the confusion arises about settings that are user-related, while OMHO should be "hardware related"
08:44alkisg has quit IRC
08:46
<markit>
anyone in this channel that can tell me how he solves this issue? even in gnome, should be the same
09:25MorningSon has quit IRC
09:32MorningSon has joined #ltsp
09:35F-GT has quit IRC
09:43jhutchins_lt has joined #ltsp
09:45alkisg has joined #ltsp
10:11F-GT has joined #ltsp
12:18z0r0 has quit IRC
12:26mistik1 has quit IRC
12:28mistik1 has joined #ltsp
12:36artista_frustrad has quit IRC
13:44mistik1 has quit IRC
13:44mistik1 has joined #ltsp
13:56
<klausade>
markit: one moment. I have a ltsp-client that is always on, displaying the nagios status of all our servers. There we had the same problem with the screen going into black.
13:58
markit: here it is, it's a four line long script that we run when the user logs in (we use kde). The content of .kde/Autostart/noblank.sh is:
13:58
#!/bin/sh
13:58
xset -dpms
13:58
xset s off
13:58
xset s noblank
15:38jhutchins_lt has quit IRC
15:41GodFather has joined #ltsp
16:10alkisg has quit IRC
16:10alkisg has joined #ltsp
16:20
<markit>
klausade: back: thanks a lot
16:20
so I'd only to put in each user's home
16:21
<klausade>
markit: you also have other places where you can put it, like in /usr/share/autostart/ i guess-
16:21
<markit>
klausade: I'm too ignorant about the insight of kde, unfortunatly
16:22
I'll ask around and google a little. Thanks a lot
16:22
<klausade>
gnome and others have pretty much the same possibilities to autorun stuff.
16:23
<johnny>
i think i put that in the ltsp scripts directory somewhere
16:23
there was an equivalent for gnome that didn't involve editing the global gconf
16:23
<markit>
johnny: is this documented in ltsp doc? Seems pretty important in school setups
16:24
<johnny>
why is it important for schoo lsetups?
16:24
what's wrong with blanking?
16:24
<markit>
expecially when used with italc or (in the future) alkisg script
16:24
<johnny>
i always blank mine
16:24
italc isn't affected by blanking
16:24
<markit>
and the screen of the teacher is sent to all children
16:24
<alkisg>
My script isn't affected too
16:24
<markit>
ah, did not know
16:24
nice to know after a day of struggle :(
16:24
<johnny>
you mean because the students are just watching and not doing stuff so the timeout is too long?
16:24
<alkisg>
It calls xset etc to disable the screensaver
16:24
<johnny>
err too short
16:25
<markit>
johnny: exactly
16:25
<johnny>
markit, apps like totem (the movie player in gnome) use the inhibit dbus call
16:25
so. blame your apps :)
16:25
apps can tell dbus to tell the x server to not blank
16:26
vs just blanking globally
16:26
i blank mine in my cafe setup
16:26
people just wiggle the mouse and their in
16:26
<markit>
johnny: never faced the issue. Yesterday while testing noticed that the ltsp client screens went blank, and thought would have been a big problem if they have the teacher's screen displayed
16:26
<johnny>
markit, well those apps should inhibit the screensaver themselves
16:26
<markit>
also because becomes blank after very few minutes, probably 10
16:26
<johnny>
not all do
16:26
but they can
16:26
<markit>
good to know, thanks
16:26
<johnny>
i'm sure there are reasons why an app might not..
16:27
like if i'm running compile in a terminal.. my screen will blank
16:27
i could tell it not too condtionally
16:27
via dbus send with the right stuff
16:27artista_frustrad has joined #ltsp
16:27* alkisg likes the screens going blank after 10 minutes... lets the students focus on the real board when it's used
16:27
<johnny>
yes.. that too alkisg :0
16:27
it also saves power
16:28
<markit>
alkisg: I've not yet had a look at your app, but the file dgross sent me is a sort of xml
16:28
<johnny>
markit, this is a relatively recent development (5 years) before that there was no semi unified framework for apps to tell the system when and when not to inhibit
16:28
<markit>
so seems your app have strings "external" to the source code
16:28
and should be easy to localize... or should be based upon a totally different mechanism to be "right"?
16:29
<alkisg>
markit: you open the glade file with the glade-3 program
16:29
It's a UI editor
16:29
Something like the delphi form designer...
16:31
<johnny>
hah.. i'm turning into a unix graybeard :(
16:31
<markit>
alkisg: do you have the url of your program handy? and any instruction about how to "install"?
16:31
<alkisg>
You mean the ppa?
16:31
sudo add-apt-repository ppa:ts.sch.gr
16:31
sudo apt-get update
16:31
sudo apt-get install sch-scripts
16:32
That's all, then you create the fat/thin chroot from the menus
16:32artista_frustrad has quit IRC
16:32
<alkisg>
Clients are automatically detected, no need for config files etc
16:33
But ... greek only, depends on dnsmasq, adds greek locale to the chroot etc, not suitable as is. That's why I'm proposing to wait 2 years until the i18n version.
16:33
<markit>
I've already thin client chroot created... will it overwrite it? do I have to remove it first? when/how "inject" dgross translated file?
16:33
(I'm using dnsmasq fortunatly)
16:33
<alkisg>
I think dgroos installed sch-client on the chroot manually
16:34
..and, ask him about the "injection process", or see the #edubuntu logs, we had some hours there trying to set it up for international use...
16:34* alkisg wouldn't want to go through it again until it's properly i18n :)
16:34
<markit>
is it split among a "server" part for visualization, and a chroot one that provides the connection to the server part?
16:34
<alkisg>
Yes
16:35
The chroot part is a simple script that only takes 1 MB RAM
16:35
<markit>
for each client?
16:35
<alkisg>
On each client
16:36
<markit>
fabolous low footprint
16:36
<alkisg>
The server network backend is based on twisted, it doesn't add much overhead per client
16:36
<markit>
how can I grab the "sources" so I can install manually?
16:36
<alkisg>
You don't need the sources, use the ppa
16:36
Just don't use the chroot generation wizard
16:37
Use your existing chroot..
16:37
<markit>
I see, thanks!
16:37
<alkisg>
Here are the sources (which you won't need): http://bazaar.launchpad.net/~sch-devs/sch-scripts/trunk/
16:38
<markit>
svn? git? mercurial?
16:38
<alkisg>
bazaar = bzr :)
16:39
<markit>
ah, don't know about bazaar... to be sincere, I can barely use git and nothing more
16:39
<alkisg>
bzr pull lp:sch-scripts
16:39
<johnny>
stupid bzr :(
16:39
canoncial bad :(
16:39
they should have used hg
16:39
:(
16:39
<markit>
hg?
16:39
<johnny>
mercurial
16:39
it's what mozilla uses
16:39
among other big projects
16:39
<alkisg>
Why not git?
16:39
<johnny>
bzr's only main user is launchpad
16:39
<markit>
aren't many moving to git?
16:40
<johnny>
well lots of canonical stuff is python.. so an importable version control system is useful
16:40
as a library
16:40
certainly many valid complaints of git for it's UI
16:40
and versioning
16:40
bzr tries to hide teh hashes
16:44
<markit>
btw, my clients are underpower for "fat clients", do you think that run some app like "local app" is a good idea or is higly risky of messing everything?
16:44
like firefox, that seem to eath ram and cpu like a dog
16:44
<alkisg>
How much ram?
16:44
<markit>
(maybe removing flash plugin will help a lot)
16:45
some 256MB, most 512MB
16:45
well not most.. half and half
16:45
kde4 should run decently with 512MB, though
16:46
<alkisg>
I'd (automatically) use thin for the 256 ones, and fat for the 512 ones
16:46
<markit>
(my test show that 384 is the bare minimum)
16:46
alkisg: you told me, do you have to provide a "table", a config file that says how much ram each client (mac address) has?
16:47
<alkisg>
No, the current code does it automatically based on the client ram
16:47
<markit>
stunning
16:47
<alkisg>
So you wouldn't need any config files
16:47
Just a fat chroot
16:48
<markit>
are the home still in the host system, or in the fat chroot?
16:48
<alkisg>
Host
16:48
<markit>
and users have to be created in the host system or in fat chroot?
16:49
<alkisg>
Host, it's ltsp as you know it...
16:49
<markit>
fabolous... so the ONLY problem is keep in sync installed programs / versions and global kde config among host (used by the teacher and thin clients) and fat chroot
16:49
<alkisg>
You just have to maintain 2 images (server+chroot) instead of 1 (server)
16:50
<markit>
well, in any case is far simple than single installations for sure!
16:51
alkisg: last question... your "script of wonders" is going to be included in -buntu (and hope debian) distro, once i18l?
16:51
<alkisg>
No idea
16:51
I'll try to push it in debian sometime in the far future, not sure if I'll be able to do it..
16:52
<markit>
seems so good that I would ask canonical at least if can do the work asap, instead of wait 2 years
16:52
<alkisg>
I don't think canonical wants to spend money on developing a classroom administration app
16:53
<markit>
do you think that an ruby programmer + (debian + kde lover) like me could easely help the i18n?
16:54
<alkisg>
Nope, pygtk knowledge would be required as the infrastructure isn't there
16:54
<markit>
I see
16:55
<johnny>
well.. there is ruby gtk..
16:55
<markit>
also ruby qt
16:55
<alkisg>
...but that would require a complete rewrite :)
16:55
<markit>
but I would love have alkisg work fine and be i18l
16:56* alkisg too
16:56
<markit>
instead of "reinvent the wheel" before have at least one project workig
16:56
the final goal would be have the "core" and 2 interfaces, gtk and qt
16:56
<johnny>
is the problem making the app il8n or the translations and stuff themselves?
16:56
<markit>
instead than 2 different projects
16:57
<johnny>
if the 2nd.. then you can use launchpad's translation service
16:57
<alkisg>
I'd love to see a web site where local school admins can upload their lists of packages + configuration tasks, and that future classroom administration tool just asking the teacher which region he's in, and doing everything automatically for him...
16:57
<johnny>
ifthe first, wrapping the cals is easy
16:57
alkisg, can't you already do that?
16:57
conary :)
16:57
err sorry.. foresight linux
16:57
<alkisg>
We have code that installs specific packages in the chroot, greek apps for primary, secondary etc education
16:57
<johnny>
but i woud be suprised if that didn't already exist
16:58
<alkisg>
That's not easy to internationalize
16:58
<johnny>
greek apps?
16:58
what is a greek app?
16:58
<alkisg>
An infrastructure would need to be developed for school admins to configure their own setups, so that teachers can automatically use them
16:58
johnny: http://ts.sch.gr/repo/images/education-menu.png
16:58
Dozens of greek-only edu apps
16:59
<markit>
and windows - wine converted, right?
16:59
so proprietary software :(
16:59
<alkisg>
Flash, windows etc, yes
16:59
<markit>
don't you feel gulty for that? lol
17:00
<alkisg>
Nope, I just did the packaging, I didn't write the software requirements :)
17:01
<markit>
alkisg: you are injecting proprietary software to the childrens of your country
17:01
<alkisg>
Nope
17:01
I'm just making the same software that they use on windows, available on linux
17:01
Otherwise they wouldn't use linux
17:01
<markit>
(btw, is only "small talk" with you, nothing serious)
17:02
<alkisg>
There are cases (few, fortunately) where the student book uses/teaches a specific app, if that app isn't available on linux, they won't use it
17:02
<markit>
alkisg: because there are not native sw that are as good as those ones, or because teacher are lazy and want to find the programs they are used to?
17:03
I ask because I'm starting to face the same problem
17:03
<alkisg>
Because the ministry paid for those programs, and wrote books that teach them
17:03
So the teacher can't really select which software to use
17:04
<markit>
"oh, I use program XXX, does it run here too?" me: "well, you can use YYY", teacher "oh, can't I use XXX? works so well, and.. 100 weak reasons"...
17:04
<alkisg>
We're trying to persuade the ministry to develop floss software from now on, but we can't change what's already been done
17:04
<markit>
alkisg: ok, anyway is a good news
17:05
I've the feeling that here in italy is the book printer that selects software to include in the book
17:05
<alkisg>
markit: e.g. do you know of any floss program that teaches the orthodox religion?
17:05
Or the greek geography?
17:05
Etc etc
17:06
The ministry developed some apps, we just need to use those
17:06
<markit>
I see
17:06
btw, they could provide as FOSS, but windows only, that would be a pity also
17:06
<alkisg>
(it's usually one app for each book, and the books are distributed by the government, the teacher can't select which book to teach)
17:07
<markit>
while gtk and qt let you create one that works in windows AND gnu/linux
17:07
<alkisg>
If they were foss, at least we could try to make them run native on linux
17:07
<markit>
but probably developers only use Visual Studio .NET these days
17:07
<alkisg>
E.g. there are a lot of flash apps that could run native, but they're not foss
17:08
<markit>
wondering if there are people here from different EU countries that can tell me about their situations
17:08
I'm very curoius about this subject
17:09
btw, ltsp server you usually deploy, is simple sata or raid10 with fast controller and write back cache?
17:10
because if it has to server 16-20 pc, I/O could be a severe bottleneck
17:10
but usually I've read about ram and cpu requirements (and gbit nick for the server)
17:11
<alkisg>
The network is the most significant part, imho
17:11
We have small classrooms of up to 12 PCs, so we're just using simple PCs as servers
17:11
4GB RAM, a simple sata disk, core 2 duo or similar, and a switch with at least 1 gigabit port
17:12* alkisg wants to try bonding on gigabit pci-e network cards though...
17:12
<stgraber>
if you can, store the files on SAN exported as NFS (with a few tweaked I can get a good 250MB/s from it) and then have dual-gigabit from that to a switch with your servers, then the HDD in the server doesn't really matter (that's for centralized deployment)
17:13
<markit>
oh, I've a 8GB ram, 4core xeon 32something, and I've the fear will be too slow! that's why I'm thinking about fat clients
17:13
<stgraber>
alkisg: I had to start using bonding for all my appservs and file servers at the office, the disk controlers were just too fast for gigabit ;)
17:13
markit: for how many clients ?
17:13
<markit>
oh, someone else alive in addition to me, alkisg and johnny! hi stgraber
17:13
16 clients
17:14
<stgraber>
16 clients on that kind of hardware won't be an issue
17:14
in some cases I run 50 clients on similar hardware (though firefox is running as localapp)
17:14
<markit>
FF is what I feart will put everything in it's kneew
17:15
fear
17:15
<stgraber>
yep, one single firefox+flash can take half of what you have ;) so that's why you want it as localapp
17:15
<alkisg>
stgraber: is there any advantage in using SAN + bonding instead of some embedded RAID, for single server setups?
17:16
<markit>
I've simulated startup and logged all 16 clients. KDE at first log creates it's directory structure in home dir and try to "migrate don't know what". I saw 4core at 100% for some minutes and was very scared
17:16
<stgraber>
yes, kde is an issue ;)
17:16
last kde we deployed was kde3 with 8.04 then we switched all our customers to gnome
17:17
<markit>
alkisg: btw, from my experience with proxmox, forget about "on board sata raid", and if you but a sas/sata RAID board, use with BBU (battery backup) and enable write through, otherwise will be VERY slow
17:17
<stgraber>
gnome scales quite well once you do a few config changes, currently the server I'm running with the most thin clients runs something like 100-150 concurent gnome sessions
17:17
and it's just a dual-quadcore-i7 (appears as 16 cores) with 24GB of RAM
17:18* alkisg didn't have any disk bottlenecks so far, as the server caches most of the needed data in RAM for my small setups...
17:18
<markit>
stgraber: more or less, what kind of "gnome changes"? maybe I can get some tip for kde also
17:19
<stgraber>
alkisg: depends on the controler, if you buy some actual decent controler like HP's P4xx serie, you should be good. Just forget about these cheap kind-of-RAID controlers you get on some computers.
17:19
<alkisg>
Right, I've heard enough problems to know to avoid that :)
17:19
<stgraber>
markit: patched glib and libc (at least for a while) to avoid having them read /proc/mounts (syncronous kernel call ...) every-time a thin client logs in
17:20
markit: at some point we'd have 100 process trying to access /proc/mounts at the same time, making the load go at something like 120 from time to time
17:20
we patched glib+libc to have them read /etc/mtab instead
17:21
that way we can filter it (as we mount most shares with "mount -n") and as it's an actual file, it gets cached and can be access asyncronously
17:23
<markit>
so not gnome specific...
17:26
stgraber: are your's school installato of of what kind?
17:26
s/of of/or of
17:26* markit is becoming too tired, not enough sleep does not forgive
17:27
<alkisg>
markit: not all ltsp installations are schools :)
17:27
<markit>
alkisg: that's why I'm asking
17:27
I dubt is for office
17:27
since GNU/linux seems not to be able to gain "professional" usage attention
17:30
<alkisg>
http://www.revolutionlinux.com/
17:30
They do deploy for offices to, afaik
17:31
<markit>
well, you have people to migrate to OOo, abandon Outlook, have accounting programs for gnu/linux, etc
17:31
not an easy task
17:32
technically is ok, but...
17:32
like you that have to package wine apps
17:32
the "old chains" are very strong
17:32
<stgraber>
sorry, just got back.
17:32
markit: I'm the main developer of ltsp-cluster at Revolution Linux
17:33
markit: we have 10 or so mass deployments of LTSP in schools as well as usage in public administation and companies
17:33
<markit>
stgraber: oh! incredible people you find in irc, lol
17:33
stgraber: what country?
17:33* alkisg adds "and the current ubuntu ltsp maintainer" :)
17:33
<stgraber>
markit: Canada
17:33
alkisg: yeah, that too ;)
17:33
<markit>
lol, nothing more?
17:33
:)
17:33
<stgraber>
a few more things but not too many LTSP-related ;)
17:33
<alkisg>
He's also running for president, but he keeps it a secret :D
17:34
<stgraber>
alkisg: shhh ;)
17:34
alkisg: btw, are you coming to BTS ?
17:34
<alkisg>
stgraber: unfortunately no :(
17:34
It didn't work out....
17:35
<stgraber>
doh ... would have been great meeting you there
17:35
<alkisg>
Yeah, I was looking forward to meeting you all in person... :-/
17:35* alkisg hopes for a EU bts some time in the future :)
17:35
<markit>
stgraber: I see you have some eeepc pictures... had problems to make them boot properly
17:36
I've the feeling that Gbit pxe firmware does not work good with ltsp
17:36
<stgraber>
alkisg: sadly there aren't many of us in Europe (anymore ;))
17:36
<markit>
(like did not worked with some fujitsu pc I'm using, had to install 1.0 and not 1.0.1 gPXE that makes nic work at 100mbs)
17:37
<alkisg>
markit: try the current git, 1.0.1 has some known problems. If that doesn't work, ask in #etherboot
17:38
<markit>
alkisg: is there something I can ask and about you don't know the answer? :)
17:39
<alkisg>
"what's the meaning of life"?
17:39
...oh no I know that, "42"...
17:39
:P
17:39
<markit>
alkisg: I'm scared to ask, since I suspect you know the answer...
17:39
lol
17:39
<alkisg>
(from the hitchiker's guide to the galaxy... nice book)
17:39
<markit>
I know :)
17:40
btw also "on board pxe" fails
17:40
so I think could be a "ltsp side" problem, not pxe one
17:41
and works with 1.0 because has not e1000 driver
17:41
so probably runs the nic at slower speed in some compatibility mode
17:41
just my guess
17:42
<alkisg>
LTSP isn't related to the pxe code, it just uses the tools
17:42
So if there's a bug, it's either in the nic rom, in dnsmasq, or in tftpd
17:43
<markit>
alkisg: sure, I use "ltsp" in the wrong way
17:43
I always mean "server side"
17:44
I understand why johnny was upset yesterday, just I don't realize it
17:44
<alkisg>
A wireshark dump would reveal the problem...
17:44
<markit>
when I write
17:44
I've tried
17:44
seems that the packets flow, but very slow
17:44
I don't see retransmission or whatever
17:44
just a slow flow of packets
17:44
<alkisg>
Which part is slow? The server or the client?
17:44
<markit>
maybe I could try again
17:45
I've tcpdumped the server side
17:45
<alkisg>
E.g. when the server receives a dhcp request, it should answer in a few msec
17:45
<markit>
dhcp is very fast
17:45
the slow part is at
17:45
"loading vmlinuz..."
17:45
that takes, i.e. 4 minutes
17:45
<alkisg>
That's tftp + pxe stack on the nic
17:46
<markit>
then the stage "initrd.img..." takes another 4-5 minutes
17:46
<alkisg>
Again, a dump + a bug report against the tftp server will get you on your way
17:46
<markit>
and after 10min you are in gdm, you login and you are fast as hell (very fast)
17:46
<alkisg>
If it proves to be a problem on your nic, then you should contact the laptop manufacturer :)
18:06
Anyone knows if udevadm is there on debian initramfs?
18:07
<markit>
I'm on debian sid, if is something you can tell me how to check, I'll be happy to help
18:11
<alkisg>
mkdir /tmp/initramfs && cd /tmp/initramfs && gunzip -c /initrd.img | cpio -i -d -H newc --no-absolute-filenames && find . -name udevadm
18:15moldy_ is now known as moldy
18:31jhutchins_lt has joined #ltsp
18:32vagrantc has joined #ltsp
18:37
<alkisg>
vagrantc: hi, is udevadm there on the debian ltsp initramfs? I think we need a `test -b /dev/nbd0 || udevadm settle` before running nbd-client...
18:44* vagrantc looks
18:46
<alkisg>
mkdir /tmp/initramfs && cd /tmp/initramfs && gunzip -c /initrd.img | cpio -i -d -H newc --no-absolute-filenames && find . -name udevadm
18:46
<vagrantc>
lsinitramfs
18:47jhutchins_lt has quit IRC
18:47
<vagrantc>
alkisg: i see sbin/udevadm
18:47
at least on squeeze
18:47
<alkisg>
Thanks, that's fine
18:48
I'll tell some people to test that fix on their systems that experience the nbd problem on monday...
18:57dgroos has joined #ltsp
19:02
<markit>
alkisg: sorry, was away and missed your request
19:02
I've seen vagrantc catch it thoug, fortunatly
19:08alkisg has quit IRC
19:10jhutchins_lt has joined #ltsp
19:13artista_frustrad has joined #ltsp
19:16F-GT has quit IRC
19:18artista_frustrad has quit IRC
19:27jhutchins_lt has quit IRC
19:28F-GT has joined #ltsp
19:38F-GT has quit IRC
19:42rjune has quit IRC
19:52ogra_cmpc has quit IRC
19:55rjune has joined #ltsp
20:04ogra_cmpc has joined #ltsp
20:05markit has quit IRC
20:06F-GT has joined #ltsp
20:12dgroos has quit IRC
20:26markit has joined #ltsp
20:44
<highvoltage>
can anyone else access the BTS 2010 wiki page fine?
20:45
chromium tells me that the page refers to itself in a loop and then stops the page
21:02ogra has quit IRC
21:04ogra has joined #ltsp
21:13markit has quit IRC
21:35jconlon has joined #ltsp
21:39
<jconlon>
I am struggling to get an HP t5135 to work. It has a via chipset but hen I try to use XSERVER= via or openchrome it freezes. Only works with vesa but slow tho.
21:41
<pmatulis>
re local app (say firefox), why does one need to specify SEARCH_DNS parameter in lts.conf? why isn't normal dhcp provisioning (domain-name-servers) sufficient?
21:42leio has quit IRC
21:45leio has joined #ltsp
21:46
<vagrantc>
pmatulis: because it wasn't fixed until very recently.
21:46
<pmatulis>
vagrantc: ah, a bug
21:47
vagrantc: do you know which version of LTSP has the fix? or which release of ubuntu will have it?
21:48
<vagrantc>
pmatulis: should be fixed in debian 5.2.4-2
21:48
pmatulis: added a patchc from bzr.
21:52
<pmatulis>
vagrantc: darn, ubuntu 10.10 will have 5.2.4-0
21:53
<vagrantc>
pmatulis: should be able to get it patched to support it
21:54
stgraber: you should apply the patch i have for debian to support dhcp's dns server configuration
21:54
stgraber: er, the patch i have in debian's ltsp...
21:54
<pmatulis>
vagrantc: yeah. now i wonder why it took so long to fix said bug. seems SEARCH_DNS has been around a long time
21:56
<vagrantc>
i think, up until recently, most LTSP installs didn't need DNS
21:58
<pmatulis>
vagrantc: ah right. local apps are recent
22:16jconlon has quit IRC
22:45mistik1_ has joined #ltsp
22:47mistik1 has quit IRC
22:47mistik1_ is now known as mistik1
22:52pmatulis has quit IRC
22:54artista_frustrad has joined #ltsp
22:59artista_frustrad has quit IRC
23:58vagrantc has quit IRC