[00:04] <mib_qg4fl9tt> need help setting up vnc on edubuntu
[00:04] <mib_qg4fl9tt> can someone help?
[00:54] <nothingman> hey, mib
[00:54] <nothingman> oh, nm
[01:09] <Meshezabeel> Heya Ahmuck
[01:24] <nothingman> hi, Mesezabeel
[01:24] <nothingman> er
[01:24] <nothingman> if I could type
[01:24] <nothingman> Meshezabeel
[01:36] <Meshezabeel> haha, hi nothingman :)
[01:36] <Meshezabeel> ever heard of TAB completion? :p
[02:21] <nothingman> heh
[02:21] <nothingman> Meshezabeel: got it now
[02:21] <Meshezabeel> :)
[02:21] <nothingman> didn't realize chatzilla had it
[02:21] <Meshezabeel> how's your day going?
[02:21] <nothingman> very well
[02:21] <nothingman> had a good sales day at my store
[02:21] <Meshezabeel> awesome :)
[02:21] <nothingman> actually, a kickass weekend
[02:22] <Meshezabeel> wow, what do you sell if you don't mind me asking
[02:22] <nothingman> computers, TVs, scanners, cameras
[02:22] <nothingman> I work at a RadioShack
[02:23] <Meshezabeel> ah, I see. Here in Canada all the Radioshack's were closed down/maybe bought out by The Source
[04:17] <nothingman> so I heard
[04:18] <nothingman> mine's nice, and I know some people in RS's in the area who I like
[13:40] <gypsymauro> hi
[13:40] <gypsymauro> there is a DVD version of edubuntu? or a localized version in italian?
[15:34] <morehpperliter> hello?
[16:33] <morehpperliter> Is there a way to reset the network config on an edubuntu LTSP server?
[16:33] <morehpperliter> I had a bad network card and now none of the PXE's can see it
[16:35] <alkisg> You changed the network card on the server and now the clients won't boot?
[16:35] <alkisg> What does `sudo invoke-rc.d dhcp3-server status` say?
[16:36] <alkisg> morehpperliter: ^^^
[16:36] <morehpperliter> I am rebooting.
[16:36] <morehpperliter> Will advise in just a moment.
[16:37] <morehpperliter> Also is there a reason VNC has trouble connecting?
[16:38] <morehpperliter> Dhcp3 is running.
[16:39] <morehpperliter> I suppose it could be another bad NIC
[16:39] <alkisg> dhcp is running, and the client's don't get an IP address? Maybe you have another dhcp server running in your network?
[16:39] <morehpperliter> I have them isolated.
[16:40] <alkisg> Well, try to connect to the server from a normal PC to see if the NIC works ok...
[16:40] <alkisg> E.g. ssh to the server
[16:41] <redtoadx> have you tried either tcpdump or ethereal to watch dhcp conversation ?
[16:41] <morehpperliter> No.
[16:42] <morehpperliter> I can only see one NIC btw.
[16:42] <alkisg> Why, how many do you have?
[16:43] <morehpperliter> two.
[16:43] <morehpperliter> I thought that was mandatory.
[16:43] <alkisg> Not really
[16:44] <morehpperliter> i.e. one to the WAN and one to lan.
[16:44] <alkisg> If you only see one nic, and the other one's not working, and your clients are connected to the non-working NIC, then... :)
[16:44] <morehpperliter> great...
[16:44] <alkisg> What does ifconfig -a give you?
[16:44] <morehpperliter> I just installed a new. hold on.
[16:45] <morehpperliter> eth0 is 192.168.1.119
[16:45] <morehpperliter> and eth2 is 192.168.0.1
[16:45] <alkisg> And where does dhcp listen on? eth2?
[16:45] <alkisg> sudo dpkg-reconfigure dhcp3-server
[16:47] <morehpperliter> non-authoritative version of DHCP server
[16:47] <morehpperliter> ...
[16:48] <ogra> alkisg, UGH !
[16:48] <ogra> never do that
[16:48] <alkisg> What? :)
[16:48] <ogra> dpkg-reconfigure dhcp3-server
[16:48] <alkisg> ogra, why not? it works fine...
[16:48] <ogra> it disables al self test features
[16:48] <ogra> by forcing an interface
[16:49] <alkisg> Erm... not really, you may put an empty interface there
[16:49] <ogra> so your config wont be checked anymore
[16:49] <ogra> look at the code
[16:49] <ogra> really, dont put an interface in there
[16:49] <alkisg> Ah, the ltsp code? OK, I'm hearing you :)
[16:49] <ogra> no, the dhcpd code
[16:50] <ogra> simply leave it with the defaults
[16:50] <ogra> they were selected for a reason :)
[16:50] <alkisg> ogra: "The interfaces will be automatically detected if this field is left blank."
[16:50] <morehpperliter> Ok.
[16:50] <ogra> alkisg, right
[16:50] <alkisg> That's what I was saying, to check if there was already an interface there (the wrong one, e.g. the non-existent eth1)
[16:50] <morehpperliter> Top right hand corner next to the sound is a network connections
[16:51] <morehpperliter> It says.
[16:51] <morehpperliter> Wired networks (Dell Xtreme ) the onboard
[16:51] <morehpperliter> -Wired connection 2
[16:51] <morehpperliter> -Wired connection 1
[16:51] <morehpperliter> -Auto Eth0
[16:51] <ogra> alkisg, ah, well, i wouldnt use debconf for that ;) grep IFACE /etc/default/dhcp3-server
[16:51] <ogra> ;)
[16:52] <morehpperliter> Auto ethe zero is checked.
[16:52] <morehpperliter> NExt is
[16:52] <alkisg> ogra, well, I tried to find this file, but I looked at /etc/dhcpd so I couldn't find it :P :D
[16:52] <morehpperliter> Wired network (Kingston)
[16:52] <morehpperliter> Wired connection 2 is checked.
[16:52] <morehpperliter> Is that right?
[16:53] <alkisg> morehpperliter: Well, the names of the connections do not mean something (at least to me).
[16:53] <morehpperliter> Ok.
[16:54] <morehpperliter> I was trying to find out if the defaults were still right.
[16:54] <alkisg> Do this: cat /etc/default/dhcp3-server
[16:54] <alkisg> And paste here the INTERFACES line
[16:55] <ogra> by default it should be INTERFACES=""
[16:55] <morehpperliter> INTERFACES="eth2"
[16:55] <ogra> if not, make it look like that
[16:55] <ogra> is eth2 physically the device your thin client network is connected to ?
[16:56] <morehpperliter> Yes. I have it connected to  a swtich.
[16:56] <morehpperliter> I have also tried direct.
[16:56] <ogra> and you are sure the devices are the right way round, the cable isnt in the wrong one
[16:58] <morehpperliter> pretty sure.
[16:59] <morehpperliter> Though I cannot connect to IRC on it ...
[16:59] <morehpperliter> So maybe something else is up.
[16:59] <ogra> you might have mixed up the two interfaces ... try changing the cables around
[17:00] <alkisg> ogra, btw, why /etc/ltsp/dhcpd.conf is used instead of /etc/dhcp3/dhcpd.conf ?
[17:00] <ogra> alkisg, so that installing ltsp-server-standalone doesnt break your dhcp setup
[17:01] <ogra> that way admins can just delete /etc/ltsp/dhcpd.conf which is a conffile, and dpkg will respect that ... you can easily go on using /etc/dhcp3/dhcpd.conf and we dont need to mangle existing configs
[17:02] <morehpperliter> Nope
[17:02] <morehpperliter> I am changing cables completely.
[17:02] <morehpperliter> JIC
[17:02] <ogra> and if you dont use /etc/dhcp3/dhcpd.conf yet, it will provide you a default config that works out of the box (at least from CD installs)
[17:02] <alkisg> Ah! I didn't know that if /etc/ltsp/dhcpd.conf was deleted, then /etc/dhcp3/dhcpd.conf would be used... Thanks, ogra
[17:03] <ogra> the trick is that we use the dpkg conffile mechanism which means it will never be restored
[17:04] <alkisg> morehpperliter: why don't you try pinging the server from another PC? It's a lot more easier to test connectivity with ping than messing with dhcp server...
[17:04] <morehpperliter> I deleted the wired connection 1 and 2.
[17:04] <morehpperliter> I am online now.
[17:05] <ogra> ok, at least one cable is right and at least one connection is configure crorrectly then
[17:05] <ogra> can you put the output of ifconfig -a and the content of /etc/network/interfaces on paste.ubuntu.com for us ?
[17:06] <morehpperliter> yes.
[17:08] <head> http://paste.ubuntu.com/118886/
[17:08] <morehpperliter> Its called head...
[17:08] <morehpperliter> For some reason.
[17:08] <ogra> you still didnt fox your /etc/default/dhcp3-server
[17:08] <ogra> *fix
[17:09] <ogra> remove eth2 there
[17:09] <ogra> and show the content of your /etc/network/interfaces as well
[17:13] <head> Im confused
[17:13] <head> How do you want me to remove it?
[17:13] <ogra> edit the file, so it looks like: INTERFACES=""
[17:13] <alkisg> sudo vi /etc/default/dhcp3-server
[17:14] <ogra> or sudo nano /etc/default/dhcp3-server if you dont get along with vi
[17:17] <morehpperliter> How do I write out?
[17:17] <ogra> with vi ?
[17:18] <morehpperliter> ctrl-o
[17:18] <morehpperliter> and ctrl-x
[17:18] <morehpperliter> Sorry.
[17:18] <morehpperliter> Not enough coffee bit of a linux-newb
[17:18] <head> Okay so I blacked it out.
[17:18] <ogra> thats fine, we all started somewhere :)
[17:18] <head> Okay so I blanked it out.
[17:18] <ogra> good
[17:18] <head> I'm more into hardware hacking.
[17:19] <ogra> now paste the content of your /etc/network/interfaces file
[17:19] <ogra> cat /etc/network/interfaces
[17:19] <ogra> and drop that inot paste.ubuntu.com
[17:19] <ogra> *into
[17:20] <head> http://paste.ubuntu.com/118889/
[17:20] <ogra> hmm
[17:21] <ogra> http://paste.ubuntu.com/118886/ shows that you dont have an eth1
[17:21] <alkisg> ogra, I think it'd be easier if he modified  /etc/udev/rules.d/70-persistent-net.rules to change eth2 to eth1
[17:21] <alkisg> He changed NICs
[17:21] <ogra> but http://paste.ubuntu.com/118889/ hows that you tried to configure it
[17:21] <ogra> aha
[17:21] <ogra> ok
[17:21] <ogra> sudo nano /etc/network/interfaces
[17:21] <ogra> replace eth1 with eth2
[17:22] <ogra> in line 13 and 14 of http://paste.ubuntu.com/118889/
[17:22] <head> got it.
[17:22] <ogra> save the file and reboot ... all should work then
[17:22] <head> ok.
[17:22] <head> Thanks.
[17:22] <morehpperliter> Thanks so much.
[17:22] <ogra> alkisg, well, easier is relative :)
[17:23] <ogra> alkisg, but yes, that would be an option as well
[17:23] <morehpperliter> this has been an enjoyable Irc visit.
[17:23] <alkisg> Yeah, but he may get into trouble later on with eth0 and eth2 with no eth1... he'll mix them up :)
[17:23] <ogra> come back if you have more questions :)
[17:24] <ogra> alkisg, given that there will never be an eth1 i doubt that will be an issue
[17:24] <Lns> gooooooood morning vietnaaaam! =p
[17:24] <alkisg> Heeeey Lns :)
[17:24] <ogra> eth0 is always the outbound facing interface ... and *the other* is the TC interface :)
[17:25] <ogra> not to hard to keep in mind
[17:25] <Lns> hey alkisg, ogra =)
[17:25] <ogra> hey Lns
[17:27] <morehpperliter> cool its getting farther than before!
[17:27] <morehpperliter> Am I limited to on query a day?
[17:27] <ogra> heh
[17:27] <morehpperliter> Am I limited to one query a day?
[17:27] <ogra> yu have to send more virtual beer for more queries :)
[17:28] <morehpperliter> I have  a keg.
[17:28] <morehpperliter> IS remote connection disabled in edubuntu?
[17:28] <morehpperliter> I am getting the error no matchin security types.
[17:29] <alkisg> Lns, about https://bugs.launchpad.net/ubuntu/+source/ia32-libs/+bug/277069/comments/13 - did you try `chattr`? Gadi proposed it to me for a similar problem, and it was OK as a workaround...
[17:32] <Lns> alkisg: that is a good idea. Just hope it wouldn't cause any package upgrades/ldconfig to fail and leave anything in limbo by not being able to replace that symlink
[17:32] <Lns> Was thinking of implementing chattr attributes for .desktop files that i customize too so they don't get overwritten upon program upgrade
[17:32] <Lns> its just hard to keep note of all the "little things" I do to a server, to keep track =) I need to implement a wiki for all the servers i care for
[17:33] <alkisg> Lns, I've no idea, I tried it for pxelinux.cfg/default (not in a package) and for some other file in /etc (don't remember which), and had no problem so far...
[17:33] <Lns> alkisg: yeah.. im sure it would probably work fine
[17:34]  * Lns wants to implement a gui for automated thin-client shutdown/startup that can be used by "normal" techs (i.e. don't like the commandline) - to alter times for shutdown/startup...and possibly package it with some help
[17:35] <alkisg> Lns, you already have the scripts, don't you? It should be easy to use pygtk or something...
[17:36] <Lns> alkisg: well they're not really scripts as much as howtos
[17:36] <Lns> not sure how much i can put into an automated script thing..they use cron - so i think i could probably just use root user-based cron jobs instead of altering /etc/crontab, etc.
[17:39] <morehpperliter> On setting up LTSP cient...
[17:39] <morehpperliter> Disconnecting: que, disconnect, sock, done
[17:40] <morehpperliter> [  18.719276] nbd0: Recieve control failed (result -32)
[17:40] <morehpperliter> Any thoughts?
[17:40] <ogra> how did you install ltsp on the server ?
[17:41] <morehpperliter> Alternative install disk. [F4 ]
[17:41] <morehpperliter> Intstall LTSP server.
[17:46] <ogra> hmm, that should be fine then
[17:47] <ogra> did you change other setup options like the  dpkg-reconfigure dhcp3-server you did ?
[17:47] <ogra> oh, and does it actually stop booting at that point ?
[17:51] <morehpperliter> I dont think I changed anything else.
[17:52] <morehpperliter> And yes it stops.
[17:58] <morehpperliter> I'm using rom-o-matic's ehterboot.
[17:58] <ogra> that should be fine
[17:59] <morehpperliter> Trying it with a EEE's I get a vsync error. Which I expected due to screen size.
[17:59] <morehpperliter> resolution...
[18:00] <ogra> but it finishes booting ?
[18:00] <morehpperliter> No
[18:01] <morehpperliter> Kernel panic.
[18:01] <morehpperliter> I have an MSI wind sitting here.
[18:01] <morehpperliter> Let me grab another machine...
[18:01] <ogra> how do you get to a vsync error if you have a kernel panic ?
[18:01] <ogra> X starts way after the kernel has booted
[18:02] <morehpperliter> Sorry.
[18:02] <morehpperliter> It's a sync error.
[18:03] <ogra> hmm
[18:03] <morehpperliter> usb  problems.
[18:03] <ogra> ah
[18:03] <ogra> what did you say you use ? 8.10 ?
[18:04] <morehpperliter> Newest.
[18:05] <ogra> lsb_release -r
[18:05] <ogra> what does that tell you ?
[18:07] <morehpperliter> 8.20
[18:07] <morehpperliter> 8.10
[18:07] <morehpperliter> Sorry..
[18:08] <ogra> ok
[18:09] <ogra> if you use modern HW like an eee or wind you should use PXE rather
[18:09] <ogra> instead of etherboot
[18:09] <morehpperliter> right I am.
[18:09] <ogra> newer HW ususally has PXE capable network cards
[18:09] <morehpperliter> I get the USB error.
[18:09] <ogra> you said you use rom-o-matic
[18:10] <ogra> thats etherboot or gpxe
[18:10] <morehpperliter> Yes.
[18:10] <ogra> not PXE
[18:10] <morehpperliter> On a way old gates computer.
[18:10] <ogra> ah
[18:10] <morehpperliter> I also have a eee that is going straight into PXE.
[18:15]  * ogra must admit he's a bit out of ideas, probably the guys in #ltsp have more ...
[18:16] <morehpperliter> Ok thanks.
[18:16] <Lns> morehpperliter: both machines can't boot?
[18:16] <morehpperliter> Yup.
[18:16] <Lns> morehpperliter: did you customize your chroot at all?
[18:16] <morehpperliter> Nope.
[18:17] <Lns> morehpperliter: have you upgraded your chroot to latest packages?
[18:17] <morehpperliter> I ran all updates. Can I manually force this?
[18:17] <ogra> Lns, he'S running 8.10, that should be fine with the default set
[18:17] <Lns> ogra: k..just going through the motions :)
[18:18] <ogra> right, dont let me stop you :)
[18:18] <Lns> hehe
[18:18] <Lns> morehpperliter: you ran all updates INSIDE the chroot?
[18:18] <Lns> or just on the server?
[18:18] <morehpperliter> Is there a way I can check this?
[18:18] <morehpperliter> Just the server I suppose.
[18:18] <Lns> morehpperliter: this howto is for hardy, so change it for ibex: https://help.ubuntu.com/community/UbuntuLTSP/UpdatingChroot
[18:19] <Lns> ogra: real quick, it's a good idea to mount --bind /dev in chroot when upgrading right? I always get a "cannot open /dev/pty blah blah" when upgrading.. if so, can you give me the best mount cmd to put into the howto?
[18:22] <ogra> no, no good idea
[18:24] <Lns> ogra: umm... not a good idea, or yes a good idea? :)
[18:24] <ogra> not a good idea
[18:24] <Lns> oh
[18:24] <Lns> ok, sounds like a plan to me hehe
[18:24] <ogra> blindly giving the chroot access to all servers HW is never a good idea ....
[18:25] <ogra> if anything goes wrong you trash the complete server
[18:25] <Lns> gotcha
[18:25] <ogra> sudo chroot $ROOT mkdir -p /dev/pts
[18:25] <ogra> sudo chroot $ROOT mount -t devpts devpts -o noexec,nosuid,gid=5,mode=620 /dev/pts
[18:25] <ogra> and dont forget to unmount it at the end
[18:26] <Lns> ogra: does ltsp-update-image look for mounted /dev/pts as it does /proc?
[18:26] <ogra> nope
[18:26] <Lns> k
[18:27] <ogra>  /dev/pts isnt needed for anything
[18:27] <Lns> ogra: maybe just easier to disregard those msgs then
[18:27] <ogra> its just cosmetic
[18:27] <Lns> ok...i'll just put a note in there to disregard it
[18:27] <ogra> ltsp-update-image could grow a mount command indeed
[18:27] <ogra> like the above
[18:28] <ogra> file a whishlist bug and add my two lines to it :)
[18:28] <Lns> ok =)
[18:31] <morehpperliter> was that for me?
[18:31] <Lns> ogra: bug for ltsp upstream or ltsp ubuntu (both?)
[18:31] <morehpperliter> Cause I'm done now...
[18:31] <ogra> ubuntu
[18:31] <Lns> k
[18:31] <ogra> its apt thats complaining about pts
[18:32] <Lns> oh yeah..duhy
[18:32] <Lns> duh*
[18:33] <morehpperliter> Still the same problem.
[18:34] <Lns> ogra: just fyi, https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/330194
[18:39] <morehpperliter> wind booted fine
[18:39] <Lns> sbalneav: 'morning! Can you give me any updated info on https://bugs.launchpad.net/ubuntu/+source/ltsp/+bug/281498 ? I noticed while on-site at a school last Friday that all the clients still hang for a good amount of time (up to 30sec) and also causes other booting clients to not receive a DHCP lease (guessing due to heavy server i/o?)
[18:41] <morehpperliter> Cool thanks folks.
[18:42] <Lns> morehpperliter:  ? you got it going?
[18:45] <morehpperliter> Some what.
[18:46] <morehpperliter> Not nearly as bulletproof as I was told..
[18:46] <Lns> morehpperliter: it's strange that you'd be having these issues right off the bat
[18:47] <morehpperliter> Not one of my king Midas days.
[18:49] <morehpperliter> So do I setup individual User accounts now?
[18:50] <morehpperliter> I think I may have been premature in my thought that the original machine wasnt working...
[18:51] <morehpperliter> The cursor is still blinking.
[18:51] <Lns> ?
[23:33] <stgraber> Lns: around ?
[23:33] <Lns> stgraber: howdy!
[23:33] <Lns> happy 3:33. ;)
[23:33] <stgraber> Lns: hi, just got a bunch of mail from LP about your nbd bug, when exactly are they crashing ?
[23:34] <Lns> stgraber: they *hang* at "Negotiation: "
[23:34] <stgraber> so when they're reconnecting the NBD ?
[23:34] <stgraber> or right after the initramfs ?
[23:35] <Lns> stgraber: during swapfile creation i believe.
[23:35] <Lns> lemme dig up the code
[23:35] <stgraber> is that with stock Intrepid ?
[23:35] <stgraber> because I fixed that race condition in Jaunty and in my PPA for Intrepid
[23:36] <stgraber> at least I used to have that bug with some powerful thin clients and now it continues booting just fine (the kernel message is the expect behavior, nothing weird there)
[23:36] <Lns> stgraber: http://pastebot.ltsp.org/253 - no, it's hardy.
[23:36] <Lns> i know, hardy is ancient... :)
[23:37] <Lns> the quote issue has been fixed, and that might *help* the issue, i need to test. I hadn't done that fix at all my sites
[23:38] <Lns> in:   if [ -n "$(ps ax|grep nbd$i)" ]; then
[23:38] <stgraber> oh, Hardy :) I have no idea what we have in Hardy's init scripts :)
[23:38] <stgraber> I fixed a few NBD issues in Intrepid and tried to clean up most of the init scripts
[23:39] <Lns> stgraber: any possibility of an SRU for hardy? pretty please? :)
[23:39] <stgraber> if someone does it yes :)
[23:39] <Lns> I can test it!
[23:39] <stgraber> I don't have the time required to cherry-pick the fixes and prepare a SRU
[23:39] <Lns> I'm not good enough to cherry pick them
[23:39] <stgraber> doing a SRU for Hardy will fix a lot of bugs for sure but will also take a lot of time as most things have been rewritten upstream since then :)
[23:40] <stgraber> well, I already gave up doing the SRUs for Intrepid so for Hardy ...
[23:40] <Lns> when's the next lts out?
[23:40] <Lns> that's my determining factor for upgrading.
[23:40] <Lns> (as many others)
[23:40] <stgraber> for now my LTSP work is: Make it rocks in the current devel release and backport everything to the previous one
[23:40] <stgraber> I unfortunately don't have the time to do the updates :(
[23:41] <stgraber> likely 10.04
[23:41] <Lns> stgraber: Yeah, that's what I get from most devs unfortunately :) the testing releases are always priority over stable
[23:41] <Lns> ugh..that's a long time
[23:41] <Lns> I sure wish there was an easier mechanism for getting things into Hardy..like an LTS update team or something
[23:41] <Lns> there's no way production environments can run a non-stable release
[23:42] <Lns> i tried...it was too much for me. way too much
[23:42] <stgraber> what I do for my customers with LTSP cluster is: Application server running the latest stable (currently Intrepid), nbd root on the latest stable (currently Intrepid) and all the infrastructure (dns, dhcp, web servers, ldap, ltsp-cluster services) on LTS
[23:43] <stgraber> with LTSP being a backport from the devel version
[23:43] <stgraber> I usually test the new devel version on my own network (at home), then at the office, then pushed to my customers
[23:43] <Lns> I dunno about running the ibex on all my servers
[23:44] <Lns> i know its considered stable, but its definitely not as worked through as hardy
[23:44] <stgraber> for application servers its fine and if you want working localapps, you don't have the choice as hardy's ssh is too old
[23:44] <Lns> for one simple thing to go wrong with any aspect of the system, i have 7 techs screaming at me
[23:45] <Lns> right...localapps is one thing that lures me
[23:45] <Lns> my situation is that i'm the only one that administrates (in this fashion) my 9 LTSP networks
[23:45] <stgraber> well, I manage >3k thin clients network and >30k users each :)
[23:46] <Lns> so any changes need to be absolutely bulletproof
[23:46] <Lns> stgraber: yeah but you're not the only one! =)
[23:46] <Lns> you have backup, i don't ;)
[23:46] <stgraber> currently, we're 2 or 3 to manage 5 school districts or something like that :)
[23:47] <stgraber> I'm mainly doing the devel and debug part of the work though
[23:47] <Lns> stgraber: you work for canonical right? or no?
[23:47] <stgraber> nope
[23:47] <Lns> oh! thought you did.
[23:47] <stgraber> Revolution Linux
[23:47] <Lns> oh wow, didn't realize
[23:48] <Lns> the pulse flash guys! ;)
[23:49] <LaserJock> Lns: -updates does need to be fairly bulletproof
[23:49] <Lns> LaserJock: for ibex or hardy?
[23:49] <LaserJock> both
[23:49] <Lns> well
[23:49] <Lns> which one is *more* bulletproof ;)
[23:49] <stgraber> rules are the same
[23:49] <LaserJock> that's why we need people testing -proposed
[23:49] <Lns> and which one, overall, has less issues?
[23:50] <LaserJock> I'm not sure
[23:50] <stgraber> not sure actually :)
[23:50] <Lns> heh
[23:50] <Lns> well
[23:50] <LaserJock> depends on the packages
[23:50] <stgraber> I tend to report bugs in Intrepid and make sure they're fixed there
[23:50] <stgraber> not in Hardy
[23:50] <Lns> OOo, firefox..
[23:50] <stgraber> so desktop is probably better in Intrepid I'd say
[23:50] <stgraber> Hardy is probably better for the server part though
[23:51] <Lns> but things move so much faster with non-lts...new bugs are introduced with new packages that are just waiting to be reported
[23:51] <Lns> the timed release thing is a positive thing for lts
[23:51] <LaserJock> I don't think there's any difference with LTSes
[23:51] <LaserJock> substantial differences anyway
[23:51] <Lns> well what the hell makes it LTS worthy then?! =p
[23:52] <LaserJock> it has longer term support
[23:52] <LaserJock> hence L T S ;-)
[23:52] <Lns> support != bugfixes though, obviously
[23:52] <Lns> since they're getting fixed in the newer versions first
[23:52] <LaserJock> it can
[23:52] <stgraber> I'm usually using OpenVZ (chroot with resource limitations and network emulation) for my systems. The host being hardy, then each service is in its own VZ with its own IP and the best release for it
[23:52] <LaserJock> it generally has the same level of support, just for a longer about of time
[23:52] <stgraber> so for a DNS server I'd use unbound from Intrepid, for a web server, hardy, for an application server, intrepid, ...
[23:53] <stgraber> advantage of OpenVZ being how fast it's, it's basically improved chroot so no side-effect like real virtualization (xen/kvm)
[23:54]  * Lns wonders why he always gets confused when discussing benefits of LTS vs. non-LTS
[23:56] <stgraber> currently my rule is that all physical server must run a LTS release (so I don't have to upgrade the host every 1.5 year), then run OpenVZ VMs in whatever release is the best
[23:56] <Lns> I would have to assume that being on a LongTermSupport version means that you are supported for a longer amount of time...but it seems the support provided is second-tier to the non-LTS (read: devel) versions, which imho, is a complete oxymoron situation
[23:56] <LaserJock> well, it's more *length* than *amount* of support
[23:56] <LaserJock> nah, it's just not always easy
[23:57] <Lns> LaserJock: well that's like saying "For the more stable version, we'll support you for longer, but you have to wait longer for fixes, if we even backport/SRU it"
[23:57] <Lns> which is like a false sense of stability
[23:57] <stgraber> well, developers should be focusing on developing. Though that means a second group of people who take care of the updates, unfortunately there isn't enough of them.
[23:57] <LaserJock> it's also harder to backport as you go along
[23:57] <Lns> i understand
[23:58] <LaserJock> so Hardy got a heck of a lot updates early on
[23:58] <stgraber> Lns: who said "more stable" ? We're just speaking about long term support, imho Hardy wasn't a good release
[23:58] <LaserJock> now that Intrepid is out it's hard to do more
[23:58] <stgraber> we had to wait 8.04.1 to get something really stable
[23:58] <Lns> stgraber: well that's the thing. you'd think support == stability, since it's being supported
[23:59] <Lns> it just seems so weird to me.
[23:59] <LaserJock> well, support is support
[23:59] <LaserJock> stability ends up being how much you screw around with things
[23:59] <LaserJock> compared to when you started
[23:59] <Lns> LaserJock: not if there's issues with the stock binaries/scripts