IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 26 March 2012 (all times are UTC)
| 02:07 | adrianorg_ has left IRC (adrianorg_!~adrianorg@177.18.170.194, Ping timeout: 250 seconds) | |
| 02:25 | tessier has left IRC (tessier!~treed@216.105.40.125, Changing host) | |
| 02:25 | tessier has joined IRC (tessier!~treed@kernel-panic/copilotco) | |
| 03:29 | alexqwesa has joined IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net) | |
| 04:34 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 05:29 | bauerski has joined IRC (bauerski!~witekb@frodo.psp.opole.pl) | |
| 05:51 | Trixboxer has joined IRC (Trixboxer!~Trixboxer@115.124.115.71) | |
| 06:21 | siahos has left IRC (siahos!968c0b30@gateway/web/freenode/ip.150.140.11.48, Quit: Page closed) | |
| 06:50 | dobber has joined IRC (dobber!~dobber@213.169.45.222) | |
| 06:53 | Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Ping timeout: 272 seconds) | |
| 07:22 | Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com) | |
| 07:39 | monteslu__ has joined IRC (monteslu__!~monteslu@ip68-109-174-213.ph.ph.cox.net) | |
| 07:43 | monteslu_ has left IRC (monteslu_!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 272 seconds) | |
| 08:21 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 09:00 | StevePerry has joined IRC (StevePerry!~StevePerr@CPE-124-178-180-118.lns4.pie.bigpond.net.au) | |
| 09:03 | <StevePerry> hey guys
| |
| 09:03 | any chance anyone can help me with my sanity with ltsp/rdesktop + centos 6.2 >.>
| |
| 09:05 | i cant connect to anything with rdesktop through pxe, im out of ideas as to why.."black screen with cursor only"
| |
| 09:06 | all hosts can ping each other and such.
| |
| 09:06 | SCREEN_07=rdesktop
| |
| 09:07 | any suggestions on where/what to check ?
| |
| 09:11 | <Hyperbyte> StevePerry, is your chroot also Centos 6.2?
| |
| 09:12 | <StevePerry> Scientific Linux 6.1 i think
| |
| 09:12 | i could be wrong >.>
| |
| 09:12 | <Hyperbyte> cat /opt/ltsp/i386/etc/issue
| |
| 09:13 | 'i386' could be something else
| |
| 09:13 | <StevePerry> Scientific Linux 6.1
| |
| 09:17 | monteslu__ is now known as monteslu | |
| 09:18 | <Hyperbyte> StevePerry, what happens if you do a regular install of Scientific Linux 6.1, and then use rdesktop from that to connect to your server?
| |
| 09:18 | (perhaps SL 6.1 has a live CD you can try with?)
| |
| 09:18 | Gremble has joined IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com) | |
| 09:18 | <StevePerry> ill give it a go and find out
| |
| 09:18 | ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de) | |
| 09:21 | bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) | |
| 09:45 | <Hyperbyte> My god... I just found out about the upcoming HTC One S
| |
| 09:45 | * Hyperbyte drools | |
| 09:46 | <StevePerry> im waiting on samsung galaxy s3
| |
| 09:46 | >.>
| |
| 09:46 | one day...
| |
| 09:47 | hey i just ran scientific linux 6.1 livecd, and rdesktop connected to my servers fine
| |
| 09:47 | >.<
| |
| 09:47 | was kinda hoping it didnt
| |
| 09:48 | any ideas on what to try/look for from here ?
| |
| 09:48 | ive got nothin
| |
| 09:58 | xsl has joined IRC (xsl!~silence@unaffiliated/xsl) | |
| 10:04 | xsl has left IRC (xsl!~silence@unaffiliated/xsl, Quit: Connection reset by fear) | |
| 10:11 | alexqwesa_ has joined IRC (alexqwesa_!~alex@109.172.12.47) | |
| 10:12 | alexqwesa has left IRC (alexqwesa!~alex@alexo-veto.broker.freenet6.net, Ping timeout: 245 seconds) | |
| 10:13 | <Hyperbyte> StevePerry, hmm... me neither (someone else might though)
| |
| 10:13 | Can you pastebin your lts.conf?
| |
| 10:25 | <StevePerry> yeah
| |
| 10:25 | anything else i should put up ?
| |
| 10:41 | toscalix has joined IRC (toscalix!~toscalix@62.87.117.194) | |
| 11:10 | StevePerry has left IRC (StevePerry!~StevePerr@CPE-124-178-180-118.lns4.pie.bigpond.net.au, ) | |
| 11:13 | risca has left IRC (risca!~risca@wnpgmb0903w-ds01-249-233.dynamic.mtsallstream.net, Quit: Lämnar) | |
| 11:14 | adrianorg_ has joined IRC (adrianorg_!~adrianorg@177.18.170.194) | |
| 11:39 | toscalix has left IRC (toscalix!~toscalix@62.87.117.194, Ping timeout: 246 seconds) | |
| 12:07 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 265 seconds) | |
| 12:12 | artista-frustrad has joined IRC (artista-frustrad!~fernando@200.247.43.2) | |
| 12:42 | <alkisg> ogra_: "unless you really need to force the lower depth ..." ==> isn't halfing the bandwidth a good enough reason?
| |
| 12:42 | <ogra_> i think you will see a lot of banding on cheap LCDs with that
| |
| 12:44 | <alkisg> I haven't noticed that... actually, when I have 2 VMs booted on the same screen, one with 16bpp and one with 32bpp, I have a hard time to tell which one's which
| |
| 12:45 | <ogra_> then you have good panels ;)
| |
| 12:45 | <alkisg> And from 76 mbps to 38 mbps, even if one can put his eyes close enough to the screen to tell the difference, I think he'll still appreciate more his video not lagging
| |
| 12:45 | Or his xterm scrolling better, etc etc
| |
| 12:57 | <ogra_> well, up to you guys, its not that i (want to) have anything to say wrt dev decisions ;)
| |
| 12:58 | * ogra_ will likely do some development next release, but only for new architecture support | |
| 13:03 | <alkisg> ogra_: you do know that we always appreciate your wisdom. :) I don't think anyone has actually seen real world problems with 16 bpp though (except with nv on TNT2, but now we've switched to nouveau)
| |
| 13:07 | mikkel has joined IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk) | |
| 13:15 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Read error: Connection reset by peer) | |
| 13:15 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 13:16 | <Hyperbyte> alkisg++
| |
| 13:18 | * alkisg also committed a DNS_SERVER=auto option... getting ready for ltsp-server-php... ;) | |
| 13:19 | <Hyperbyte> ltsp-server-php?
| |
| 13:21 | * Hyperbyte shakes alkisg up and down | |
| 13:21 | <Hyperbyte> If you're doing something with PHP I need to know about it!
| |
| 13:21 | <alkisg> !learn ltsp-server-pnp as An alternative to ltsp-server-standlone, this package uses dnsmasq in proxyDHCP mode, doesn't mind if an external dhcp server is around (e.g. a router), ships a default lts.conf that focuses on speed, etc etc
| |
| 13:21 | <ltsp> alkisg: The operation succeeded.
| |
| 13:21 | <Hyperbyte> ....
| |
| 13:21 | <alkisg> More when it's ready :D
| |
| 13:21 | <Hyperbyte> What does this have to do with PHP?
| |
| 13:21 | Oh
| |
| 13:21 | PNP
| |
| 13:21 | <alkisg> pnp == plug and play
| |
| 13:22 | * Hyperbyte smacks alkisg | |
| 13:22 | <Hyperbyte> Yeah
| |
| 13:22 | <alkisg> And put bigger glasses :P
| |
| 13:22 | <Hyperbyte> Then actually -write- PNP please!
| |
| 13:22 | <alkisg> Oooouch
| |
| 13:22 | <Hyperbyte> 15:18 ≡ alkisg/#ltsp also committed a DNS_SERVER=auto option... getting ready for ltsp-server-php... ;)
| |
| 13:22 | * alkisg slaps himself | |
| 13:22 | * Hyperbyte smacks alkisg again! | |
| 13:22 | <Hyperbyte> :-D
| |
| 13:22 | <alkisg> Hey I got today's dose, no more please, I'll get bruises :P
| |
| 13:23 | <Hyperbyte> I'll make sure to not leave any. :P
| |
| 13:23 | <JesseC> so wait, ltsp-server-pnp comes with the dnsmasq setup for dhcp proxying?
| |
| 13:23 | <Hyperbyte> !ltsp-server-pnp | echo JesseC
| |
| 13:23 | <ltsp> JesseC ltsp-server-pnp: An alternative to ltsp-server-standlone, this package uses dnsmasq in proxyDHCP mode, doesn't mind if an external dhcp server is around (e.g. a router), ships a default lts.conf that focuses on speed, etc etc
| |
| 13:23 | <Hyperbyte> :P
| |
| 13:23 | <alkisg> JesseC: that's the idea, although it's not ready yet, the first alpha will be out in a week or so
| |
| 13:23 | <JesseC> Yeah I read that, was confirming that I read it correctly. =(
| |
| 13:24 | <Hyperbyte> I'm just being silly. ;-)
| |
| 13:24 | <alkisg> I'll put it in a PPA for 12.04, and if many people want it, we can ship it with ubuntu for 14.04
| |
| 13:24 | <JesseC> dnsmasq was pretty easy to setup though, ~10 minutes
| |
| 13:24 | <alkisg> That focuses on people that don't know how to do "sudo gedit /etc/dnsmasq.d/*"
| |
| 13:25 | Just install ltsp-server-pnp from synaptic, done, no need to install dnsmasq or configure it or create an lts.conf etc
| |
| 13:25 | <JesseC> I think you told me to ready the guide at least 5 times and that's how I learned to do it. haha
| |
| 13:25 | read even..
| |
| 13:25 | <alkisg> It'll also have nice pxe menus
| |
| 13:26 | http://alkisg.mysch.gr/steki/index.php?action=dlattach;topic=2828.0;attach=1672;image
| |
| 13:26 | Ah and it'll support using vbox to manage your chroots
| |
| 13:26 | No ltsp-build-client or ltsp-update-image anymore
| |
| 13:26 | <JesseC> speaking of all this fancy new stuff
| |
| 13:26 | bauerski has left IRC (bauerski!~witekb@frodo.psp.opole.pl, Quit: Leaving.) | |
| 13:26 | <elias_a> alkisg: Really? That's something!
| |
| 13:27 | <alkisg> elias_a: many people are switching to fat clients, and chroots aren't really handy for managing fat disks
| |
| 13:27 | <elias_a> alkisg: I understand.
| |
| 13:27 | <JesseC> So we will be able to boot into the image using vbox
| |
| 13:27 | <elias_a> I think it is a very good thing.
| |
| 13:27 | <JesseC> and modify the image directly, gui and all?
| |
| 13:28 | <alkisg> Yes
| |
| 13:28 | <elias_a> Wow!
| |
| 13:28 | <JesseC> =DDD
| |
| 13:28 | <alkisg> Although an "ltsp-publish-image" is still required, that'll be handled by a GUI
| |
| 13:28 | (advanced users can directly export the vbox image, but not regular users)
| |
| 13:28 | <elias_a> Is this channel logged publicly?
| |
| 13:28 | <alkisg> !logs
| |
| 13:28 | <ltsp> alkisg: logs: http://irclogs.ltsp.org/
| |
| 13:29 | <elias_a> Just wanted to know because I want to quote todays discussion to a mailing list.
| |
| 13:29 | <alkisg> elias_a: note that those are _my_ plans, not upstream ltsp's plans
| |
| 13:30 | But if many people start using ltsp-server-pnp, I guess it'll eventually end up in distros too, not just in a PPA
| |
| 13:30 | <elias_a> alkisg: σας ευχαριστώ!
| |
| 13:31 | Message understood :)
| |
| 13:31 | <alkisg> ole hyvä :)
| |
| 13:31 | <Hyperbyte> You guys are messing up my terminal. :'(
| |
| 13:31 | <elias_a> Kiitos!
| |
| 13:31 | <alkisg> Hyperbyte: get a utf-8 capable terminal :D
| |
| 13:31 | <elias_a> Hyperbyte: UTF-8 rules!
| |
| 13:31 | <Hyperbyte> Noobs. :(
| |
| 13:32 | <elias_a> ooo - one more channel to start UTF-8 wars on.... :)
| |
| 13:32 | <Hyperbyte> Actually my IRC client isn't UTF-8 capable I think.
| |
| 13:32 | <elias_a> Hyperbyte: What are u using?
| |
| 13:33 | <Hyperbyte> Something so ancient it's pathetic.
| |
| 13:34 | BitchX-1.1-final+ by panasync - Linux 2.6.34.9-69.fc13.x86_64
| |
| 13:35 | <andygraybeal_> zentyal has released a ltsp integrated module!!
| |
| 13:36 | <elias_a> Hyperbyte: Oh that's a little aged, I agree...
| |
| 13:36 | <Hyperbyte> elias_a, nostalgia. :-)
| |
| 13:37 | <elias_a> I have to say I just love running irssi+screen in a shell...
| |
| 13:37 | Hyperbyte: It'll soon have vintage value... :)
| |
| 13:37 | <Hyperbyte> I do the same thing, but with BitchX. :-)
| |
| 13:49 | Gremble has left IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com, Quit: I Leave) | |
| 13:50 | <||cw> Hyperbyte: for a minute there I thought you were going to say pirch
| |
| 13:51 | back in the day I wrote a little tray-app that listed for pirch dde commands and use ms's text to speach engine to read IRC to me
| |
| 13:53 | s/listed/listened/
| |
| 13:59 | <Hyperbyte> =)
| |
| 13:59 | That'd be pretty easy to do with BitchX, if I weren't running it in a virtual screen terminal. :-)
| |
| 14:05 | dead_inside has joined IRC (dead_inside!~dead_insi@76.75.3.174) | |
| 14:11 | artista-frustrad has left IRC (artista-frustrad!~fernando@200.247.43.2, Read error: No route to host) | |
| 14:26 | artista_frustrad has joined IRC (artista_frustrad!~fernando@200.247.43.2) | |
| 14:26 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 14:26 | khildin has joined IRC (khildin!~khildin@ip-80-236-227-194.dsl.scarlet.be) | |
| 14:30 | <||cw> yeah, it wasn't hard then either, but I was "green" and it was my first forte into DDE, which is an odd little beast
| |
| 14:30 | <Hyperbyte> :)
| |
| 14:51 | staffencasa has joined IRC (staffencasa!~staffenca@128-193-148-207.oregonstate.edu) | |
| 14:52 | bengoa has joined IRC (bengoa!~bengoa@2001:1291:229:2:216:cbff:feab:6cc9) | |
| 14:56 | bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) | |
| 14:58 | Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com, Ping timeout: 240 seconds) | |
| 15:06 | leio has left IRC (leio!~leio@gentoo/developer/leio, Quit: No Ping reply in 180 seconds.) | |
| 15:06 | leio has joined IRC (leio!~leio@gentoo/developer/leio) | |
| 15:07 | toscalix has joined IRC (toscalix!~toscalix@235.184.219.87.dynamic.jazztel.es) | |
| 15:17 | vagrantc has joined IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net) | |
| 15:30 | risca has joined IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca) | |
| 15:36 | Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com) | |
| 15:39 | dobber has left IRC (dobber!~dobber@213.169.45.222, Remote host closed the connection) | |
| 15:59 | Mava has left IRC (Mava!~Mava@ip-45-224.dhcp.opintanner.fi, Read error: Connection reset by peer) | |
| 15:59 | Mava has joined IRC (Mava!~Mava@ip-45-224.dhcp.opintanner.fi) | |
| 16:00 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 245 seconds) | |
| 16:02 | risca has left IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca, Ping timeout: 246 seconds) | |
| 16:30 | Trixboxer has left IRC (Trixboxer!~Trixboxer@115.124.115.71, Remote host closed the connection) | |
| 16:31 | toscalix has left IRC (toscalix!~toscalix@235.184.219.87.dynamic.jazztel.es, Ping timeout: 276 seconds) | |
| 16:35 | alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg) | |
| 16:36 | <alkisg> vagrantc: heya there, so in short, do you agree or not for X_COLOR_DEPTH=auto by default?
| |
| 16:36 | <vagrantc> alkisg: dunno.
| |
| 16:37 | rthomson has joined IRC (rthomson!~rthomson@mars.pet.ubc.ca) | |
| 16:37 | <vagrantc> i got a fair number of complaints about defaulting to 16-bit, actually, so was actually happy to let X.org do it's thing.
| |
| 16:39 | the more LTSP mucks with, the more we diverge from L
| |
| 16:39 | TSP5
| |
| 16:39 | but if the performance is really better for the common use-cases...
| |
| 16:39 | <alkisg> What kind of complains though?
| |
| 16:40 | It's been a really long time since I've seen a client not supporting 16bpp...
| |
| 16:40 | (nv with TNT2, now nouveau has no problems with it)
| |
| 16:40 | toscalix has joined IRC (toscalix!~toscalix@62.87.104.103) | |
| 16:40 | <vagrantc> people complaining about "why isn't this higher color depth? it looks awful."
| |
| 16:41 | <alkisg> It does?!
| |
| 16:41 | Maybe they're talking about the ltsp logo which had 256 colors?
| |
| 16:41 | *ldm theme
| |
| 16:41 | <vagrantc> i am relaying the complains that caused me to switch...
| |
| 16:41 | <alkisg> OK, any other ones? Because I don't buy that one.. :D
| |
| 16:42 | <vagrantc> that was it... definitely numerous complaints, though
| |
| 16:42 | <alkisg> Mhm...
| |
| 16:43 | <vagrantc> X_COLOR_DEPTH=auto suggests to me to leave X.org do it's thing, though.
| |
| 16:43 | <alkisg> X_COLOR_DEPTH=unset, really
| |
| 16:43 | "By default, X_COLOR_DEPTH varies; it depends on ..."
| |
| 16:43 | "You can set a specific bpp to force it..."
| |
| 16:44 | <vagrantc> well, if we default to X_COLOR_DEPTH=auto, how do you "unset" it?
| |
| 16:44 | risca has joined IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca) | |
| 16:44 | <alkisg> X_COLOR_DEPTH=""
| |
| 16:44 | <vagrantc> that works in lts.conf?
| |
| 16:44 | <alkisg> Yes, if you have backside code to handle it
| |
| 16:44 | <vagrantc> seems... messy.
| |
| 16:44 | <alkisg> if ${X_COLOR_DEPTH-not set} ...
| |
| 16:45 | <vagrantc> i don't like having to add code like that for all of our variables.
| |
| 16:45 | <alkisg> Why for all of them?
| |
| 16:45 | We only need "smart" defaults for a few of them
| |
| 16:46 | <vagrantc> if one variables supports special behavior when unset, then it seems like it should be consiistant with all variables.
| |
| 16:46 | <alkisg> When to have nbd swap, when to force LTSP_FATCLIENT=False...
| |
| 16:46 | The special behavior is only for the special variables though, that have a "smart" default
| |
| 16:46 | * vagrantc rejects special variables | |
| 16:47 | <alkisg> OK, do you like the idea of an explicitly defined X_COLOR_DEPTH="smart" though?
| |
| 16:47 | <vagrantc> i prefer to have a feature be on, or off. and if there's some autodetection needed, you should be able to turn it on or off.
| |
| 16:47 | <alkisg> Ah. Then we could have an X_SMART_COLOR_DEPTH? :P
| |
| 16:47 | <vagrantc> maybe.
| |
| 16:47 | <alkisg> Which defaluts to true?
| |
| 16:48 | OK, let me think of better names there...
| |
| 16:48 | <vagrantc> i am of mixed mind about the whole idea.
| |
| 16:48 | <alkisg> lts.conf aside, do you like the concept of automatic detection?
| |
| 16:48 | * vagrantc re-reads the proposal | |
| 16:48 | <alkisg> Because for LTSP 6, I really want to implement a proper configuration system...
| |
| 16:48 | risca has left IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca, Ping timeout: 248 seconds) | |
| 16:49 | <alkisg> *not proper, just another, i'm not suggesting that this one is not proper, it's just too mixed up now
| |
| 16:49 | * alkisg hopes people here realize that non-english speakers don't always select appropriate words :) | |
| 16:51 | * vagrantc is forgiving and admiring of people who speak multiple languages | |
| 16:52 | <vagrantc> alkisg: so the proposal with LOCAL_APPS_MENU is a little odd ... if they're using local apps without the menu ...
| |
| 16:52 | <alkisg> We do support TIMESERVER=auto, XSERVER=auto, LIVE_UDEVD=auto, X_MOUSE_PROTOCOL=auto, and I just put support for DNS_SERVER=auto
| |
| 16:52 | But if a better name like X_COLOR_DEPTH=smart would make more sense, sure
| |
| 16:53 | vagrantc: it is indeed odd, and Ben in the mailing list prefered X_COLOR_DEPTH=16 even with localapps enabled,
| |
| 16:53 | <vagrantc> well, X_COLOR_DEPTH=auto ... i just feel like we *switched* to X.org autodetection
| |
| 16:53 | <alkisg> but I was trying to prevent complains from people that use a lot of localapps
| |
| 16:54 | <vagrantc> but definitely, a lot of FOO=auto seems to make it consistant
| |
| 16:54 | X_COLOR_DEPTH=auto in thin clients at least, seems to force 16 bit, rather than do autodetection.
| |
| 16:55 | <alkisg> Supposedly, if one has configured a local web browser and flash, he might prefer the xorg default color depth. But I believe in that case we would have configured the menu. Also, personally I wouldn't mind having 16bpp even in that case, to make xterm and all the window movements etc faster.
| |
| 16:56 | <vagrantc> i guess it's just a matter of what you're autodetecting
| |
| 16:56 | <alkisg> Btw in my original proposal, I don't want to use "auto", it'll just be the default behavior
| |
| 16:57 | <vagrantc> we're trying to detect use-cases where we would want to override the default X.org autodetection.
| |
| 16:57 | <alkisg> And if one wants to get back to the old one, he'd have to use the weird X_COLOR_DEPTH="" syntax, but I wonder how many people would actually want to do that
| |
| 16:57 | <vagrantc> alkisg: which doesn't leave a way to disable LTSP from mucking with it?
| |
| 16:57 | <alkisg> So there's no "auto" involved
| |
| 16:58 | * vagrantc doesn't like unset behaving differently from set to an empty value. | |
| 16:58 | <alkisg> Why not? If I set DNS_SERVER="", I get a different DNS server than if not setting it
| |
| 16:58 | <vagrantc> i think unset and empty should be treated the same.
| |
| 16:58 | <alkisg> (where we get it from dhcp)
| |
| 16:58 | Ah, no, currently not
| |
| 16:58 | <vagrantc> *should* be.
| |
| 16:58 | <alkisg> I *should* get a ... &
| |
| 16:58 | ^
| |
| 16:59 | Erm, let me rephrase: what would you expect with DNS_SERVER="" vs unset?
| |
| 16:59 | <vagrantc> i'd expect them to behave the same.
| |
| 16:59 | <alkisg> So how can I override the dhcp provided values?
| |
| 16:59 | And force dns=none?
| |
| 17:01 | Second proposal.. how about the default X_COLOR_DEPTH to be what I said, and having X_COLOR_DEPTH="auto" would allow falling back to the default xorg detection?
| |
| 17:02 | <vagrantc> alkisg: that would fit my concerns better.
| |
| 17:03 | setting DNS_SERVER=none might make sense.
| |
| 17:04 | <alkisg> Does that also apply for X_COLOR_DEPTH=none? :-/
| |
| 17:04 | I don't know, but DNS_SERVER="", X_COLOR_DEPTH="" sound better to me, but no problem, I just want a way to apply that smart color depth thing
| |
| 17:04 | <vagrantc> doesn't seem to make as much senese to me.
| |
| 17:04 | also, DNS_SERVER=auto would make sense to use the values provided from DHCP
| |
| 17:05 | <alkisg> I think all those questions could go away if we supported an "unset" syntax in lts.conf
| |
| 17:05 | But anyway, for now, are you ok with that last proposal?
| |
| 17:06 | Default X_COLOR_DEPTH="unnamed smart logic", and X_COLOR_DEPTH="auto" just doesn't use -depth in X
| |
| 17:07 | And forcing X_COLOR_DEPTH="" again uses the smart logic
| |
| 17:07 | risca has joined IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca) | |
| 17:07 | <vagrantc> unset or "" should be equivalent, X_COLOR_DEPTH=auto LTSP doesn't do anything (i.e. default to X.org autodetection)?
| |
| 17:08 | <alkisg> Yes
| |
| 17:08 | <vagrantc> seems fine to me.
| |
| 17:08 | <alkisg> Either that, or: we define a new name, e.g. X_COLOR_DEPTH=smart, which applies the new behavior only if set, without changing the default existing behavior
| |
| 17:08 | <vagrantc> so the "" or unset cases use 16-bit on thin-clients, and are treated as if "auto" was set in other cases.
| |
| 17:09 | <alkisg> Yes, and the only thing left is if you want that LOCAL_APPS_MENU addition or not
| |
| 17:09 | *exception
| |
| 17:10 | <vagrantc> i wouldn't do any special handling of local apps ... they can set lts.conf if they want ?
| |
| 17:10 | <alkisg> Sure
| |
| 17:11 | <vagrantc> fatclients, it's obviously better to use X.org defaults, but with localapps it seems more case-by-case.
| |
| 17:11 | <alkisg> OK, I'll push that, and commit to answer the first round of complains in the mailing list. If there are many people insisting, I'll say I'm sorry and revert to auto. :)
| |
| 17:12 | I'll also allow for defining X_COLOR_DEPTH="smart", in case that ever happens, so that people can be sure that will still work if explicitly defined
| |
| 17:12 | <vagrantc> alkisg: i think the big pool of complaints came from debian-edu, although i've not been watching debian-edu much lately.
| |
| 17:12 | <alkisg> Meh. Thin clients with tuxpaint in 32bpp?!!!
| |
| 17:13 | <vagrantc> ?
| |
| 17:13 | <alkisg> All the edu apps we use here are very slow with 32bpp
| |
| 17:13 | I really wonder why one would want 32bpp for thin clients in an educational environment
| |
| 17:13 | Meesterarend has joined IRC (Meesterarend!~meesterar@41.29.123.149) | |
| 17:13 | <alkisg> I was more worried about people that only have a couple of clients and don't mind the double bandwidth
| |
| 17:15 | risca has left IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca, Ping timeout: 260 seconds) | |
| 17:17 | <alkisg> Btw, I'm preparing "ltsp-server-pnp", that's why I'm pushing for those changes now, to get them in precise. I'll put some beta-quality code for pxemenus, automatic dnsmasq configuration etc, and we can strip the ones we want for upstream packages when we have enough feedback.
| |
| 17:19 | komunista has joined IRC (komunista!~slavko@adsl-195-168-247-102.dynamic.nextra.sk) | |
| 17:24 | Meesterarend has left IRC (Meesterarend!~meesterar@41.29.123.149) | |
| 17:26 | <alkisg> Btw #2, thanks :)
| |
| 17:42 | <highvoltage> hey Άλκης
| |
| 17:52 | <alkisg> :)
| |
| 17:53 | vagrantc: on second thought... I'm pushing X_SMART_DEPTH=True by deafult, and people can change it to False if they want
| |
| 17:53 | highvoltage: would you be interested in creating a pxelinux theme for ltsp?
| |
| 17:57 | <vagrantc> alkisg: seems reasonable too.
| |
| 17:57 | alkisg: that way we're not repurposing an existing argument, and it's easy to turn on/off
| |
| 17:57 | <alkisg> There was some complexity in the code about X_COLOR_DEPTH in configure-x and in an altlinux initscript
| |
| 17:58 | So I thought I'd opt for the easiest implementation :D
| |
| 17:58 | <vagrantc> altlinux hasn't committed code in years...
| |
| 17:58 | and configure-x should probably get removed... ?
| |
| 17:59 | alkisg: X_SMART_COLOR_DEPTH ?
| |
| 17:59 | <alkisg> Sure
| |
| 17:59 | <vagrantc> hmm...
| |
| 17:59 | * vagrantc thinks more | |
| 17:59 | <highvoltage> alkisg: I saw your messages regarding that over the weekend. I'd like to but I'd first like to get my current to-do list down a bit (which hasn't been going great the last few weeks due to playing too much minecraft), but yes, I'd like to
| |
| 18:00 | <alkisg> highvoltage: cool, yeah no hurries at all, it'll be in a PPA for starters
| |
| 18:00 | So there are no deadlines whatsoever, thanks
| |
| 18:04 | <highvoltage> k
| |
| 18:07 | <alkisg> Which one sounds better? XRANDR_COMMAND_0, XRANDR_CMD_0 or even plain XRANDR_0 ?
| |
| 18:07 | https://bugs.launchpad.net/ltsp/+bug/942608
| |
| 18:11 | toscalix has left IRC (toscalix!~toscalix@62.87.104.103, Ping timeout: 260 seconds) | |
| 18:17 | <vagrantc> alkisg: i think i like XRANDR_COMMAND_NN or XRANDR_NN
| |
| 18:17 | risca has joined IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca) | |
| 18:17 | <vagrantc> little more preference for XRANDR_COMMAND
| |
| 18:17 | <alkisg> vagrantc: ok, XRANDR_COMMAND_N it is :)
| |
| 18:17 | <vagrantc> alkisg: 0-9 ?
| |
| 18:18 | <alkisg> vagrantc: yes, the other xrandr variables are the same too, 0-9
| |
| 18:18 | I can also allow XRANDR_COMMAND_*, it makes no difference in the code complexity, if you prefer...
| |
| 18:18 | env | sed -n '/^XRANDR_COMMAND_[0-9]=/s///p' | while read command; do
| |
| 18:18 | # Remove possible "xrandr" in front of the command
| |
| 18:18 | command=${command#xrandr}
| |
| 18:18 | xrandr $command
| |
| 18:18 | done
| |
| 18:19 | <vagrantc> which, is actually executing arbitrary commands
| |
| 18:19 | <alkisg> Nope
| |
| 18:19 | <vagrantc> ah, right.
| |
| 18:20 | <alkisg> It allows for arbitrary xrandr arguments, but not running other commands
| |
| 18:20 | <vagrantc> drop support for the old variables? or shoe-horn them into the current setup?
| |
| 18:20 | * vagrantc wonders why it was done the way it is now. | |
| 18:20 | <alkisg> Dunno... I was planning to just add that
| |
| 18:20 | But I'd never use the other variables anyway
| |
| 18:20 | Except for XRANDR_MODE_0, that is
| |
| 18:21 | I think I'll leave the big XRANDR cleanup for the future, when we start using the new xorg equivalent snippets
| |
| 18:21 | E.g. PreferredMode instead of setting it with xrandr,
| |
| 18:21 | <vagrantc> it probably started with XRANDR_MODE_0, which was from X_MODE_0 ... and then just evolved from there on a per-feature basis
| |
| 18:21 | <alkisg> because that would start X at the desired resolution, instead of changing it later on and causing flicker
| |
| 18:22 | (man xorg.conf)
| |
| 18:22 | Position, LeftOf, and other fancy xrandr-supported options there
| |
| 18:25 | artista_frustrad has left IRC (artista_frustrad!~fernando@200.247.43.2, Remote host closed the connection) | |
| 18:25 | adrianorg__ has joined IRC (adrianorg__!~adrianorg@177.18.170.194) | |
| 18:29 | adrianorg_ has left IRC (adrianorg_!~adrianorg@177.18.170.194, Ping timeout: 245 seconds) | |
| 18:29 | <vagrantc> alkisg: so you've changed your mind after mailing the ltsp list regarding X_COLOR_DEPTH? :)
| |
| 18:30 | <alkisg> Yup I have to send another annoying email :)
| |
| 18:31 | artista_frustrad has joined IRC (artista_frustrad!~fernando@200.247.43.2) | |
| 18:32 | <vagrantc> alkisg: why'd you put the color depth change in screen-session.d rather than ltsp_config.d ?
| |
| 18:32 | <alkisg> vagrantc: we need to make a discussion about that, but I don't want to have a lot of ltsp_config.d variables overhead (storing, restoring etc) for variables that are only used in a single place
| |
| 18:33 | <vagrantc> so instead we autodetect it every time it runs?
| |
| 18:33 | <alkisg> Yes, if it can be autodetected with a single if, there's no point in saving/restoring it, too much overhead there
| |
| 18:34 | Let's postpone that discussion for when we redesign/clean up our configuration system
| |
| 18:34 | ogra_ has left IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de, Ping timeout: 246 seconds) | |
| 18:34 | Mava has left IRC (Mava!~Mava@ip-45-224.dhcp.opintanner.fi, Read error: Connection reset by peer) | |
| 18:35 | Mava has joined IRC (Mava!~Mava@ip-45-224.dhcp.opintanner.fi) | |
| 18:35 | ogra_ has joined IRC (ogra_!~ogra@p5098ed03.dip0.t-ipconnect.de) | |
| 18:38 | <vagrantc> alkisg: but it was something that could be detected with a two-part if?
| |
| 18:39 | <alkisg> vagrantc: ? if boolean_is_true "${X_SMART_COLOR_DEPTH:-True}" && ! boolean_is_true "${LTSP_FATCLIENT}"; then
| |
| 18:39 | That doesn't use any external commands at all.. set_lts_var writes a file, much more expensive...
| |
| 18:39 | <vagrantc> alkisg: i don't see why that couldn't go in ltsp_config.d ...
| |
| 18:39 | ah.
| |
| 18:40 | <alkisg> OK, let's discuss that a bit
| |
| 18:40 | ltsp_config.d now tries to handle everything
| |
| 18:40 | Even parts that some clients won't need
| |
| 18:40 | E.g. if a client uses SCREEN_07=shell, it doesn't care about X
| |
| 18:40 | So why not have the code run when it's actually needed?
| |
| 18:41 | <vagrantc> the logic before was ltsp_config handled setting all configuration variables, and then the rest of the stuff just responded to teh configguration
| |
| 18:41 | <alkisg> Actually ltsp_config now doesn't even use set_lts_var for all variables,
| |
| 18:42 | <vagrantc> whee.
| |
| 18:42 | <alkisg> and also half of the logic isn't in ltsp_config at all
| |
| 18:42 | It really needs a cleanup
| |
| 18:43 | <vagrantc> what sets variables that's outside of ltsp_config (other than your recent commit) ?
| |
| 18:43 | definitely needs a good cleanup, yes.
| |
| 18:45 | <alkisg> I also want to propose the rule that "variables in CAPS are exported in the environment, local script variables should use lowercase"
| |
| 18:45 | Now, one can't tell if X_ARGS is an lts.conf variable or an internal variable
| |
| 18:46 | So will configure-x.sh (which is executed) see it or not?
| |
| 18:46 | <vagrantc> alkisg: i like the CAPS/lowercase distinctions
| |
| 18:46 | <alkisg> X_RAMPERC=${X_RAMPERC:-100} => e.g. should that go in ltsp_config too?
| |
| 18:47 | Gremble has joined IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com) | |
| 18:47 | <alkisg> XCONF=/var/run/ltsp-xorg.conf.. the code is full of parts that set variables in caps
| |
| 18:48 | XSERVER=fbdev
| |
| 18:48 | Why would ltsp_config.d do an expensive `uname -m` call if X isn't going to run at all?
| |
| 18:49 | <vagrantc> guess there's some logic to that.
| |
| 18:49 | * vagrantc felt like the last BTS was a frenzy of code changes, rather than solid code review | |
| 18:49 | <alkisg> We should have a "get_lts_var XSERVER" at that point, and if it was cached, we'd avoid the uname -m the second time
| |
| 18:50 | Yeah it'd be better if we targetted more specific goals at BTS's
| |
| 18:51 | <vagrantc> you talking about client/screen-session.d/XS20-xserver-ppc-r128-hack ?
| |
| 18:51 | <alkisg> Yes
| |
| 18:51 | But there are many similar code samples all over trunk
| |
| 18:52 | <vagrantc> wonder if that should go away? http://bugs.debian.org/587900
| |
| 18:52 | sure.
| |
| 18:52 | <alkisg> So, new logic: defined points where we save and retrieve the configuration, similar to the -cluster ones
| |
| 18:52 | E.g. ldm loads them on init, before login etc
| |
| 18:53 | So XSERVER would be properly set at that case. If not, then that script would set it to fbdev.
| |
| 18:53 | Then the configuration would be saved, so it'd be there on next checks, avoiding the second uname
| |
| 18:54 | <vagrantc> alkisg: so, when you upload a package, does launchpad not automatically register the bug as "Fix Released" or whatever?
| |
| 18:54 | <alkisg> I don't have an overall design yet of course, just a general idea, it needs some more thinking
| |
| 18:55 | vagrantc: there's a bzr commit -fixes, I think that if I use it, it'll do it,
| |
| 18:55 | but it does close them on package uploads
| |
| 18:55 | Should we start using bzr commit -fixes?
| |
| 18:55 | <vagrantc> alkisg: so you haven't been manually closing all those epoptes bugs? they always seem to come several days after a release actually gets uploaded... ?
| |
| 18:56 | alkisg: i'd rather not have to use the launchpad plugins to bzr.
| |
| 18:56 | <alkisg> I think that there's some bug there, they're closed when syncing from debian, but not when directly uploading an ubuntu-specific version
| |
| 18:57 | So for the latest epoptes ubuntu upload I did have to close them manually :(
| |
| 18:57 | I haven't verified that "sync vs ubunt upload" bug though
| |
| 19:00 | <vagrantc> highvoltage: i keep forgetting to look at ltsp-cluster*
| |
| 19:00 | <alkisg> vagrantc: since LTSP bugs are reported on launchpad, I don't think it'd be bad to use -fixes for them either...
| |
| 19:01 | * vagrantc will not use features that require bzr login | |
| 19:01 | <alkisg> Ah, it requires login? OK :)
| |
| 19:03 | <highvoltage> vagrantc: we got ltsp-cluster-agent and ltsp-cluster-agent-weblive into ubuntu (by upload instead of sync), so there's no immediate rush, but it would be nice to get them into debian before freeze (do you happen to know when that is?)
| |
| 19:03 | <vagrantc> dunno.
| |
| 19:03 | highvoltage: freeze is in june.
| |
| 19:04 | alkisg: looks like it might just record metadata in the commit, which would be fine.
| |
| 19:04 | although having to remember one more thing to commit...
| |
| 19:04 | <alkisg> It's still optional, one can close the bugs manually if he doesn't remember it
| |
| 19:04 | * vagrantc wonders if you can retroactively add --fixes for previously committed stuff | |
| 19:05 | <highvoltage> vagrantc: /win last
| |
| 19:05 | (oops)
| |
| 19:05 | <vagrantc> highvoltage: might want to comment on the ITP's that they're in ubuntu
| |
| 19:06 | especially if the packaging is the same.
| |
| 19:19 | <highvoltage> vagrantc: ok
| |
| 19:26 | risca has left IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca, Ping timeout: 248 seconds) | |
| 19:39 | monteslu_ has joined IRC (monteslu_!~monteslu@ip68-109-174-213.ph.ph.cox.net) | |
| 19:43 | monteslu has left IRC (monteslu!~monteslu@ip68-109-174-213.ph.ph.cox.net, Ping timeout: 272 seconds) | |
| 19:52 | alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Quit: Leaving.) | |
| 19:53 | risca has joined IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca) | |
| 20:01 | jvin has joined IRC (jvin!~jvin@108-82-19-151.lightspeed.livnmi.sbcglobal.net) | |
| 20:03 | Lns has left IRC (Lns!~Lns@pdpc/supporter/professional/lns, Quit: Leaving) | |
| 20:07 | <jvin> If I turn off ltsp dhcp on eth1, and connect eth1 to the same switch eth0 is on (that has a router with dhcp), will clients attached on that same switch find ltsp ok (maybe need to reissue ltsp 'ssh-keys'/etc again)?
| |
| 20:09 | <Hyperbyte> jvin, LTSP can work with any dhcp server, as long as it has the correct options set.
| |
| 20:10 | An LTSP client needs to know where to find kernel image to boot, and which server is the LTSP server.
| |
| 20:10 | If these are correctly passed by the dhcp server, then LTSP clients will boot properly.
| |
| 20:10 | !dhcp
| |
| 20:10 | <ltsp> Hyperbyte: dhcp: http://wiki.ltsp.org/twiki/bin/view/Ltsp/DHCP
| |
| 20:10 | <Hyperbyte> Actually scratch that.
| |
| 20:11 | If you can't set those options on the dhcp server, you can use proxy dhcp
| |
| 20:11 | !proxy-dhcp
| |
| 20:11 | <ltsp> Hyperbyte: proxy-dhcp: https://help.ubuntu.com/community/UbuntuLTSP/ProxyDHCP
| |
| 20:19 | <jvin> Hyperbyte, the top level dhcp server is a standard ISP business/residential router so I'll have to use the proxy part. Thanks for the help! Off to experiment...
| |
| 20:26 | khildin has left IRC (khildin!~khildin@ip-80-236-227-194.dsl.scarlet.be, Quit: I'm gone, bye bye) | |
| 20:43 | pari has joined IRC (pari!~priyank-u@122.177.237.225) | |
| 20:44 | <pari> Hi I am not able to boot my client, I am a newbie kindly help
| |
| 20:45 | I have followed steps in https://help.ubuntu.com/community/UbuntuLTSP/LTSPQuickInstall
| |
| 20:45 | but I am stuck since I am trying to boot using dnsmasq
| |
| 20:46 | Parker955_Away is now known as Parker955 | |
| 20:48 | <pari> Please give some links for my guidance
| |
| 20:48 | <vagrantc> what have you done to configure dnsmasq?
| |
| 20:50 | <pari> I just installed it and it was running fine
| |
| 20:50 | <vagrantc> you're running ubuntu, i presume?
| |
| 20:50 | <pari> yes
| |
| 20:51 | <vagrantc> there should be an example dnsmasq file in /usr/share/doc/ltsp-server/examples/
| |
| 20:52 | <pari> yes
| |
| 20:52 | its there
| |
| 20:52 | <vagrantc> and you'll either need to drop a file in /etc/dnsmasq.d/ or edit /etc/dnsmasq.conf
| |
| 20:52 | <pari> ok.. and how to configure it?
| |
| 20:54 | <vagrantc> while it suppose dnsmasq, it's not really supported by default ... why not just use tftpd-hpa and isc-dhcp-server?
| |
| 20:54 | those should work out of the box ... otherwise, you'll have to experiment with the dnsmasq configuration options.
| |
| 20:55 | <pari> can you help?
| |
| 20:55 | <vagrantc> i'm trying...
| |
| 20:55 | if you just install tftpd-hpa and isc-dhcp-server it should "just work"
| |
| 20:55 | <pari> ok let me try tftpd-hpa
| |
| 20:56 | bobby_C has joined IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at) | |
| 20:56 | <vagrantc> pari: what part of the install is not working for you?
| |
| 20:56 | <pari> both are installed
| |
| 20:57 | <vagrantc> does this give you any output: pgrep -l -f 'tftpd|dhcpd'
| |
| 20:58 | <pari> 1213 /usr/sbin/in.tftpd --listen --user tftp --address 0.0.0.0:69 --secure /var/lib/tftpboot
| |
| 20:59 | can you take remote desktop for 5 min.. and let me know what mistakes I am making.? thanks
| |
| 20:59 | <vagrantc> no
| |
| 20:59 | <pari> ok
| |
| 20:59 | <vagrantc> so dhcpd isn't running?
| |
| 21:00 | you have two network cards on the server, one for internet access, and one for the thin client network?
| |
| 21:00 | <pari> no.. actually I am connected to a router and I am trying to boot client on VM
| |
| 21:00 | this is working OK sudo invoke-rc.d dnsmasq restart
| |
| 21:00 | <vagrantc> ok, so your router is doing DHCP?
| |
| 21:00 | <pari> yes
| |
| 21:01 | thats y i installed dnsmasq
| |
| 21:01 | <vagrantc> so either your router needs to be configured to give the right boot arguments, or you need to use proxydhcp
| |
| 21:01 | !proxydhcp
| |
| 21:01 | <ltsp> vagrantc: I do not know about 'proxydhcp', but I do know about these similar topics: 'proxy-dhcp'
| |
| 21:01 | <vagrantc> !proxy-dhcp
| |
| 21:01 | <ltsp> vagrantc: proxy-dhcp: https://help.ubuntu.com/community/UbuntuLTSP/ProxyDHCP
| |
| 21:02 | <pari> I followed that particular page only
| |
| 21:02 | I have already done all the things on that page
| |
| 21:02 | I have changed dhcp-range=192.168.1.2,proxy
| |
| 21:03 | when I start my VM error is coming fatal: could not read from the boot medium
| |
| 21:04 | I have already changed in Network tab value of Attached to: to Bridged Adapter
| |
| 21:05 | <vagrantc> that's more likely an issue of your virtual machine configuration
| |
| 21:05 | is the bridge attached to your physical interface?
| |
| 21:05 | <pari> that I am not sure of.. how to check?
| |
| 21:06 | <vagrantc> what virtual machine software are you using?
| |
| 21:06 | <pari> oracle VM
| |
| 21:06 | <vagrantc> don't know anything about it
| |
| 21:06 | <pari> ok...
| |
| 21:07 | <vagrantc> sudo brctl show
| |
| 21:07 | if it's using standard linux bridging
| |
| 21:08 | <pari> command not found
| |
| 21:08 | <vagrantc> then it's probably doing it's own weird thing
| |
| 21:09 | <pari> okk... is there any particular ubuntu distro which require min configuration while setting LTSP?
| |
| 21:10 | <vagrantc> ubuntu's probably one of the simplest, but you've got some unusual networking requirements...
| |
| 21:10 | <pari> ok.. so what according to you would be simplest approach to building ltsp system?
| |
| 21:11 | <vagrantc> might be simpler to set up a virtual server as well as a virtual machine in order to learn the process... presuminng your VM environment can easily set up it's own virtual network for the thin clients
| |
| 21:11 | Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Remote host closed the connection) | |
| 21:11 | <pari> okk
| |
| 21:11 | <vagrantc> the simplest setup is a computer with two network cards, one facing the internet/local network, and one dedicated for the thin client network.
| |
| 21:12 | <pari> okk...
| |
| 21:12 | thanks for your effort...
| |
| 21:12 | <vagrantc> and then a separate thin client.
| |
| 21:12 | <pari> ok
| |
| 21:12 | Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com) | |
| 21:12 | <vagrantc> installing from the ubuntu alternate CD in that environment shoulld set up a fully functional LTSP.
| |
| 21:13 | <pari> ubuntu alternate CD?
| |
| 21:13 | <vagrantc> to start messing with unusual networking environments, you really need a solid grasp of DHCP, tftp, NBD/NFS, etc.
| |
| 21:13 | <pari> okk yes
| |
| 21:13 | <vagrantc> pari: the installer mentioned in the URL you pointed me to.
| |
| 21:13 | <pari> thanks
| |
| 21:14 | Parker955 is now known as Parker955_Away | |
| 21:14 | pari has left IRC (pari!~priyank-u@122.177.237.225, Quit: Leaving) | |
| 21:15 | * vagrantc wanders off to be useless | |
| 21:16 | Gremble has left IRC (Gremble!~Ben@cpc10-aztw24-2-0-cust114.aztw.cable.virginmedia.com, Quit: I Leave) | |
| 21:19 | bengoa has left IRC (bengoa!~bengoa@2001:1291:229:2:216:cbff:feab:6cc9, Quit: Leaving.) | |
| 21:24 | artista_frustrad has left IRC (artista_frustrad!~fernando@200.247.43.2, Quit: Leaving) | |
| 21:39 | mikkel has left IRC (mikkel!~mikkel@80-71-132-15.u.parknet.dk, Quit: Leaving) | |
| 21:53 | Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Ping timeout: 246 seconds) | |
| 21:53 | FatBastard has joined IRC (FatBastard!~Gary@ip-80-238-8-128.bskyb.com) | |
| 21:57 | Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com) | |
| 22:00 | FatBastard has left IRC (FatBastard!~Gary@ip-80-238-8-128.bskyb.com, Ping timeout: 276 seconds) | |
| 22:03 | Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@cpc16-haye17-2-0-cust169.haye.cable.virginmedia.com, Quit: Leaving) | |
| 22:05 | alexqwesa_ has left IRC (alexqwesa_!~alex@109.172.12.47, Quit: Хана X'ам !!!) | |
| 22:07 | Steve_The_Pirate has joined IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com) | |
| 22:11 | komunista has left IRC (komunista!~slavko@adsl-195-168-247-102.dynamic.nextra.sk, Quit: Leaving.) | |
| 22:16 | bara has joined IRC (bara!~bara@zebar.de) | |
| 22:24 | bobby_C has left IRC (bobby_C!~bobby@85-124-22-227.teleworker.xdsl-line.inode.at, Ping timeout: 260 seconds) | |
| 22:27 | risca has left IRC (risca!~risca@wi-secure-4179.cc.umanitoba.ca, Quit: Lämnar) | |
| 22:28 | dead_inside has left IRC (dead_inside!~dead_insi@76.75.3.174, Quit: Leaving...) | |
| 22:34 | Steve_The_Pirate has left IRC (Steve_The_Pirate!~Gary@ip-80-238-8-128.bskyb.com, Ping timeout: 252 seconds) | |
| 23:12 | irule has joined IRC (irule!~irule@189.199.30.249) | |
| 23:16 | irule has left IRC (irule!~irule@189.199.30.249, Read error: Connection reset by peer) | |
| 23:20 | irule has joined IRC (irule!~irule@189.199.30.249) | |
| 23:28 | irule has left IRC (irule!~irule@189.199.30.249, Ping timeout: 260 seconds) | |
| 23:33 | irule has joined IRC (irule!~irule@189.199.30.249) | |
| 23:34 | * vagrantc just realized the problem with having all dirs in one directory for plugins | |
| 23:34 | <vagrantc> there's no way for add-ons to override the defaults.
| |
| 23:35 | i.e. if i wanted to override the plugin, i wouldn't be able to do so cleanly in an add-on package.
| |
| 23:35 | vagrantc has left IRC (vagrantc!~vagrant@c-76-115-60-19.hsd1.or.comcast.net, Quit: leaving) | |
| 23:59 | irule has left IRC (irule!~irule@189.199.30.249, Ping timeout: 276 seconds) | |