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


Channel log from 28 December 2013   (all times are UTC)

00:13staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 246 seconds)
01:15gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
01:17freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
01:20gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 246 seconds)
01:26vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
01:45gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
02:04Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.)
02:33alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 272 seconds)
02:45gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
02:56Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
04:18gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
04:23gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 260 seconds)
04:49vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
05:20gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
05:24gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 252 seconds)
05:47Phantomas1 has joined IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas)
05:48Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 272 seconds)
06:20alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
06:21gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
06:25gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 252 seconds)
06:28
<alkisg>
stgraber: pastebinit doesn't work with debian.net?
06:28
$ echo test | pastebinit -b 'http://paste.debian.net'
06:28
http://paste.debian.net/
06:29
I.e. the returned URL is wrong...
06:29
Same with fpaste.org...
06:37Phantomas1 has left IRC (Phantomas1!~Phantomas@ubuntu/member/phantomas, Ping timeout: 260 seconds)
06:41Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
06:46* vagrantc waves to alkisg
06:46
<alkisg>
Hi vagrantc!
06:47
<vagrantc>
alkisg: so, i know you said you didn't think it was worth it, but would you consider reviewing my pxelinux changes?
06:47
<alkisg>
vagrantc: sure, I will, sorry for being a little absent the last 2 days
06:47* vagrantc too
06:47
<alkisg>
To compensate, here's aoe support for ltsp: http://pastie.org/8581907
06:47
:P
06:47
<vagrantc>
i suppose i should post them somewhere
06:48
ah, cool. yet another ROOTFS option.
06:49
<alkisg>
vagrantc: the coolest thing about it is that it doesn't care about IPs and leases etc
06:49
<vagrantc>
alkisg: that's all?
06:49
<alkisg>
You can have network manager manage your IPs and still have an ethernet-based root below that...
06:50
<vagrantc>
alkisg: does that go in local/top or.. ?
06:50
<alkisg>
Yeah, basically a modprobe aoe is all that's needed
06:50
<vagrantc>
that sounds pretty awesome.
06:50
<alkisg>
local-top should be the best place for it, according to the initramfs-tools manpage
06:50
How should I name it? It's not really ltsp related...
06:51
<vagrantc>
alkisg: well, if we're shipping it in ltsp, i'd say name it ltsp-aoe, because it should really go in some aoe support package as a hook for initramfs-tools
06:52
or if it's just kernel, then it should go right into initramfs-tools
06:52
<alkisg>
OK, I'll name it aoe_ltsp to match nbd_ltsp
06:52
Ah, yeah, it's just kernel
06:52
<vagrantc>
then we should submit it to initramfs-tools
06:53
<alkisg>
Will you do the honors?
06:53
Or should I?
06:53
<vagrantc>
alkisg: what's the server-side stuff like?
06:53
alkisg: if you've got the time to at least file the inital patch, i can do follow-up. :)
06:53
<alkisg>
Nice, thanks, will do
06:53
<vagrantc>
alkisg: as it's mostly your work :)
06:54
<alkisg>
# apt-get install vblade; vblade -r 0 0 eth0 /opt/ltsp/images/i386.img (or edit /etc/vblade.conf)
06:54
<vagrantc>
then i can just test it and say "yup, it works!" and do any tweaking to the patch
06:54
<alkisg>
That's all there is for server-side...
06:54
<vagrantc>
alkisg: that's pretty cool.
06:54
<alkisg>
The cool thing is that our init-bottom script adds the cow part automatically ;)
06:54
<vagrantc>
yup
06:55
i was really happy when we figured out to use init-bottom for the cow stuff.
06:55
<alkisg>
I'd prefer it if it was in init-ltsp.d, but it's not a big deal
06:56
<vagrantc>
is it technically feasible to put in init-ltsp.d ?
06:57
we'd have to manage migrations of all the mountpoints and such, no?
06:58
before we had implemented all the cow stuff in our ltsp_nbd hooks
06:58
<alkisg>
We'd probably have to call the pivot_root etc once more, but it should be possible...
07:03
vagrantc: I'll add CMDLINE_AOE in our update-kernels.conf, ok?
07:03
Is ip=dhcp needed?
07:04* alkisg will test all our latest commits, just give me a couple of days... :)
07:07
<vagrantc>
is it always hardcoded to root=/dev/etherd/e ?
07:08
alkisg: i'm eagre to test this stuff, but i probably shouldn't keep pulling late-nighters
07:08
<alkisg>
I don't see any settings in the aoe module, so I imagine it always puts the devices there, yeah
07:08
/dev/etherd/e1.2
07:09
Where 1 == device major, 2== device minor
07:10
And btw it automatically uses all the interfaces, so you have bonding with it without the need to configure anything...
07:11* alkisg has better equipment for testing stuff at work, which is a bit far from home, that's why he's postponing the testing and wants to test all of them together at once...
07:12Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Ping timeout: 245 seconds)
07:14
<vagrantc>
alkisg: my recent pxelinux stuff: http://paste.debian.net/72803/
07:14
<alkisg>
I want to update the udhcp script too, it was never meant to be committed upstream that way
07:15
<vagrantc>
committed to upstream ltsp?
07:15
<alkisg>
Yeah
07:15
<vagrantc>
alkisg: i think the menus tend to default to the unversioned kernels now, too.
07:15
<alkisg>
It was back when I was still learning bash :)
07:15
<vagrantc>
or maybe that was some uncommitted code
07:16
<alkisg>
cp -a "$chroot/boot/." "$tftpboot/$name/"
07:16
find "$tftpboot/$name/" -maxdepth 1 ! -perm -o=r -exec chmod +r {} \;
07:16
...why not cp -r instead?
07:16
<vagrantc>
i didn't want to get into unrelated changes
07:16
<alkisg>
OK
07:16
<vagrantc>
although technically the symlinks and the pxelinux stuff are probably technically different things
07:16
hrm.
07:16
<alkisg>
But feel free to push both of them as 2 changes, I'll test everything when I go to work
07:22alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
07:23gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
07:27gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 260 seconds)
08:00staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
08:08staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 245 seconds)
08:23vagrantc has left IRC (vagrantc!~vagrant@freegeek/vagrantc, Quit: leaving)
08:24gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
08:29gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 272 seconds)
09:04bennabiy has left IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com, Ping timeout: 245 seconds)
09:05bennabiy has joined IRC (bennabiy!~Thunderbi@24-181-55-79.dhcp.gnvl.sc.charter.com)
09:24Enslaver has left IRC (Enslaver!~Enslaver@fedora/Enslaver, Read error: Connection reset by peer)
09:26gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
09:27Enslaver has joined IRC (Enslaver!~Enslaver@fedora/Enslaver)
09:30alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
09:31gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 246 seconds)
09:57sbalneav has left IRC (sbalneav!~sbalneav@50.71.200.173, Ping timeout: 272 seconds)
10:00freedomrun has joined IRC (freedomrun!~freedomru@unaffiliated/freedomrun)
10:11sbalneav has joined IRC (sbalneav!~sbalneav@50.71.200.173)
10:27
<stgraber>
alkisg: "ps aux | pastebinit -b http://paste.debian.net" works fine here
10:28gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
10:33gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 272 seconds)
10:42gdi2k has joined IRC (gdi2k!~gdi2k@222.127.254.113)
10:44
<gdi2k>
10:56
ok, got that fixed - must specify arch as part of ltsp-chroot. next question: no audio on fat clients. pulse is installed, but no hardware shows
11:46
anyone? Neither USB or on-board audio devices are showing up in pulse audio - only a "Dummy Device", which doesn't help much. I have SOUND = true for good measure but apparently that doesn't affect fat clients. I have also done the NFS_HOME thing as per https://help.ubuntu.com/community/UbuntuLTSP/FatClients
12:10gdi2k has left IRC (gdi2k!~gdi2k@222.127.254.113, Quit: Leaving)
12:20gdi2k has joined IRC (gdi2k!~gdi2k@222.127.254.113)
12:41rkwesk has joined IRC (rkwesk!5e4706c2@gateway/web/freenode/ip.94.71.6.194)
12:42
<rkwesk>
I thought I had this figured out but I'd like to confirm: Configuration 1 unmanaged switch w 1 giga port and 16 100 ports not connected directly w router Server with two nics, one gigabit to giga port on switch and one 100 bit to router directly. Clients, mixed thin and fat but all with 100 bit nics to same switch to 100 bit ports. Configuration 2 unmanaged switch w 1 giga port and 16 100 ports, one of 100 bit ports connected w ro
12:42
connected w router Server with one nic (giga) to giga port on switch Clients, mixed thin and fat but all with 100 bit nics to same switch to 100 bit ports. In both cases (I think) there should be no overload and so the possible complications with flow control are avoided. Is this correct? Richard
13:02freedomrun has left IRC (freedomrun!~freedomru@unaffiliated/freedomrun, Quit: So long and thanks for all the fish)
13:08alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
13:08
<rkwesk>
hi alki
13:09
<alkisg>
Hi Richard
13:09
I just saw your mail to ltsp-discuss, basically on both cases you may have a flow control issue
13:09
It depends on the switch and NIC of the server
13:10
<rkwesk>
why is that? where is the overload?
13:10
<alkisg>
There's no overload. The flow control issue is this:
13:11
server tries to send some data to a client. server is gigabit, client is 100mbps.
13:11
So server sends data too fast, and the client sends to the server an "ethernet pause"
13:11
Depending on the interpretation of that pause, the flow control issue will exist or not
13:12
If the server pauses sending data to that particular pc, then everything is ok
13:12
<rkwesk>
so what u describe sounds like overload to me
13:12
<alkisg>
If the server pauses sending data to all PCs, then we have the flow control issue
13:12
The problem isn't the overload, is the pause
13:12
<rkwesk>
yes, but pause is invoked by overload, no?
13:13
<alkisg>
It's just a mechanism to regulate speed
13:13
It's the same in tcp too
13:14
When someone sends too fast, the other peer says "slow down"
13:14
It's usual traffic, nothing particular there...
13:14
<rkwesk>
how can a switch w 100 port send to a 100 nic too fast?
13:16
if switch only had giga ports then, of course data goes too fast
13:16
<alkisg>
It cannot
13:16
Only if the client is stressed otherwise...
13:17
The flow control issue only appears when you have BOTH gigabit and 100mbps ports
13:17
<rkwesk>
but only when a giga port is connected to 100 nic
13:18gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
13:19
<rkwesk>
i guess i don't really understand the nuances
13:21
summing up, a 100 port cannot send to a 100 nic too fast. a pause occurs when data is ent too fast. where is the complication?
13:21
<alkisg>
Configuration 1 unmanaged switch w 1 giga port and 16 100 ports not connected directly w router Server with two nics, one gigabit to giga port on switch and one 100 bit to router directly. Clients, mixed thin and fat but all with 100 bit nics to same switch to 100 bit ports.
13:21
Question: can this setup suffer from the flow control issue?
13:22
Answer: yes, depending on the brand
13:22
unmanaged switch w 1 giga port and 16 100 ports, one of 100 bit ports connected w router Server with one nic (giga) to giga port on switch Clients, mixed thin and fat but all with 100 bit nics to same switch to 100 bit ports.
13:22
Same question/answer there too.
13:22
So to sum up, when your server<=>switch connection is gigabit, and your clients <=> switch connection is 100 mbps, then watch out when you're buying your hardware
13:23
<rkwesk>
sorry to be dense but i still see no where data being sent too fast
13:24
<alkisg>
The switch doesn't have infinite buffers
13:24
So when the buffer is full, it's the switch that notifies the server to stop sending data
13:25
<rkwesk>
only within the switch that received data from giga port and needs to send to 100 port suffers
13:26
so it is there that overload occurs, yes?
13:27
<alkisg>
Buffer overload?
13:27
I guess so, if you want to call it that way...
13:28
<rkwesk>
only this seems to be clear (to me) as overload
13:30
<alkisg>
http://en.wikipedia.org/wiki/Buffer_underrun
13:30
<rkwesk>
if an all giga switch were in place of above switch then buffer overload is replaced by client's nic suffering overlaod, right?
13:33
so whichever way we go there is agood chance of overload?
13:40ramcq has joined IRC (ramcq!~robot101@iota.hadesian.co.uk)
13:42
<ramcq>
hi folks, happy holidays :)
13:42
I've got a couple of Ubuntu Precise machines which have their ~ shared, and I've configured them to run with GNOME classic to avoid upsetting people too much
13:43
I had a question which isn't specifically about LTSP but you guys might know the solution
13:43
<rkwesk>
from what i see buffer underrun might occur when client sends to server and buffer overflow when server sends to client in original configs above
13:43
<ramcq>
is there a well-known method to set these systems up to log idle users out?
13:44
my least-bad idea so far was to backport the https://mail.gnome.org/archives/commits-list/2012-December/msg03185.html patch to the 3.2 version of gnome-session we're running
13:45
<alkisg>
Write a small script (or cron job) that uses xprintidle...
13:46
Or use a special screensaver that logs people out :D
13:47
<rkwesk>
rkwesk is signing off
13:47rkwesk has left IRC (rkwesk!5e4706c2@gateway/web/freenode/ip.94.71.6.194, )
13:49
<ramcq>
alkisg: hmm, and guess the display number from awking the output of w or something?
13:49Fenuks has joined IRC (Fenuks!~Fenuks@176.51.96.60)
13:56
<alkisg>
ramcq: if you run the script from /etc/xdg/autostart or from xsession, it already has DISPLAY and XAUTHORITY etc
13:57
If you really need to run it from cron, then you need some magic to get access to display/xauthority...
13:57
The first method is easier; the later allows you to power off inactive clients that stayed too long at the LDM prompt
13:58alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
14:07staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
14:19Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
14:34staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 246 seconds)
14:56Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Remote host closed the connection)
15:57staffencasa has joined IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu)
15:58Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
16:04staffencasa has left IRC (staffencasa!~staffenca@8-220.ptpg.oregonstate.edu, Ping timeout: 272 seconds)
16:16gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
16:17alzjqhiteluy has joined IRC (alzjqhiteluy!iamparadox@c-71-206-130-134.hsd1.va.comcast.net)
16:17|Paradox| has left IRC (|Paradox|!iamparadox@c-71-206-130-134.hsd1.va.comcast.net, Read error: Connection reset by peer)
16:17alzjqhiteluy is now known as |Paradox|
16:17gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
16:18gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
16:20Patina has left IRC (Patina!~tomas@dhcp-5-103-105-144.seas-nve.net, Ping timeout: 240 seconds)
16:20Patina has joined IRC (Patina!~tomas@dhcp-5-103-105-144.seas-nve.net)
16:50alkisg has joined IRC (alkisg!~alkisg@ubuntu/member/alkisg)
17:05Fenuks has left IRC (Fenuks!~Fenuks@176.51.96.60, Quit: KVIrc 4.3.1 Aria http://www.kvirc.net/)
17:08alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 245 seconds)
17:28markit has joined IRC (markit!~marco@88-149-177-66.v4.ngi.it)
19:04
<alkisg>
vagrantc, I had to do some changes in the packaging order to be able to build a package: https://code.launchpad.net/~ts.sch.gr/sch-scripts/ltsp-debian-packaging
19:06
*in order..
19:40alkisg has left IRC (alkisg!~alkisg@ubuntu/member/alkisg, Remote host closed the connection)
19:46Phantomas has left IRC (Phantomas!~Phantomas@ubuntu/member/phantomas, Quit: Leaving.)
20:28xet7 has joined IRC (xet7!~xet7@80-186-81-85.elisa-mobile.fi)
21:25alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
21:34jamest_ has joined IRC (jamest_!46b3939b@gateway/web/freenode/ip.70.179.147.155)
21:35jamest_ has left IRC (jamest_!46b3939b@gateway/web/freenode/ip.70.179.147.155)
22:02gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
22:03gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
22:07gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 246 seconds)
22:13gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
22:17gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
22:19alexqwesa has left IRC (alexqwesa!~alex@109.172.12.47, Ping timeout: 260 seconds)
22:22gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
22:33Phantomas has joined IRC (Phantomas!~Phantomas@ubuntu/member/phantomas)
22:45vagrantc has joined IRC (vagrantc!~vagrant@freegeek/vagrantc)
22:49
<gdi2k>
hi all, smee again. I'm struggling with fat client sound issues. Sound on thin clients works fine. 13.10 Xubuntu. I have SSH_FOLLOW_SYMLINKS = False in my lts.conf and have set everything up as per https://help.ubuntu.com/community/UbuntuLTSP/FatClients - pa volume control only lists a "Dummy Device" in Output devices. The USB headset shows in lsusb on the client, so it is being seen. Any ideas?
23:04
<markit>
gdi2k: I've no idea, I use kde, but are you absolutely sure it's a fat client?
23:05
it should see local hardware... does the client really have a sound card?
23:05
and is it supported by the os (i.e. if you boot with a live cd)?
23:15
<gdi2k>
markit, yes, definitely a fat client. I can open a terminal and see the local machine's /proc/cpuinfo
23:16
and yes, it definitely has a sound card (USB headset and onboard audio). Both work fine with a LiveCD and even as a thin client
23:16
if I do lsusb the headset is visible
23:16
but pulse doesn't want to see it
23:23gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Remote host closed the connection)
23:23gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
23:28gbaman has left IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com, Ping timeout: 246 seconds)
23:28alexqwesa has joined IRC (alexqwesa!~alex@109.172.12.47)
23:30Selveste1 has left IRC (Selveste1!~Selveste1@static-5-103-136-165.seas-nve.net, Remote host closed the connection)
23:31
<vagrantc>
wow. AoE allows for remote devices without even any networking information configured
23:32Selveste1 has joined IRC (Selveste1!~Selveste1@static-5-103-136-165.seas-nve.net)
23:35
<markit>
vagrantc: is it Ata over Ethernet? What are you doing with it? Seems that everyone goes for iSCSI instead...
23:35
(but I don't want my storage connection being routable, I want it fast and simple)
23:42
<vagrantc>
markit: yeah, ata o'er ethernet
23:43
markit: alkisg came up up with the remarkably simple stuff to use AoE for an LTSP rootfs on debian/ubuntu, and i was just testing it
23:43
haven't looked into iscsi
23:47
but AoE was pretty surprisingly simple to set up ...
23:48
will need some tweaks to configure networking, though.
23:49
which was a little suprise
23:51
<gdi2k>
I had a go with AoE a while back when I was playing with clustered file systems - worked nice
23:51
(AoE, not the clustered file systems)
23:53
<vagrantc>
heh
23:53
issues with writeability?
23:53
since LTSP only needs read-only access, that makes a lot of things simpler.
23:54
<gdi2k>
it was more config and reliability - I was playing with gluster at the time, but it was all over the place. ended up with RAID 1 on a single server
23:55gbaman has joined IRC (gbaman!~gbaman@host81-130-35-88.in-addr.btopenworld.com)
23:56
<gdi2k>
vagrantc, any experience with fat client and sound? been fighting this for too many hours and can't see where I'm going wrong
23:57
<vagrantc>
i haven't worked much with fatclients, actually
23:57
and haven't tested sound support very consistantly lately...
23:57
i really need to set up a testing lab or something.
23:58
i've been doing most testing on virtual hardware, and my setup doesn't support testing sound well, if at all.
23:59
<gdi2k>
yes, sound on VMs adds another dimension of things to go wrong