1207267684 Q * _gh_ Ping timeout: 480 seconds
1207271181 Q * dna Quit: Verlassend
1207277618 Q * fatgoose Ping timeout: 480 seconds
1207277623 J * fatgoose ~samuel@76-10-149-199.dsl.teksavvy.com
1207278907 J * balbir_ ~balbir@122.167.211.131
1207279087 Q * balbir Ping timeout: 480 seconds
1207280397 J * Infinito ~argos@201-3-21-127.gnace701.dsl.brasiltelecom.net.br
1207280554 Q * Infinito 
1207288976 Q * larsivi Remote host closed the connection
1207289847 J * Slydder ~chuck@194.59.17.53
1207290798 J * FireEgl FireEgl@2001:5c0:84dc:1:4:ff:fe00:1
1207290916 J * nkukard ~nkukard@196.212.73.74
1207291092 Q * ctrix Ping timeout: 480 seconds
1207291106 J * ctrix ~8__D@81-174-32-147.static.ngi.it
1207291649 J * mrfree ~mrfree@host1-89-static.40-88-b.business.telecomitalia.it
1207292797 J * yarihm ~yarihm@whitehead2.nine.ch
1207292815 J * _nkukard_ ~nkukard@196.212.73.74
1207292926 Q * _nkukard_ 
1207292977 Q * nkukard Ping timeout: 480 seconds
1207293248 J * nkukard ~nkukard@196.212.73.74
1207293415 Q * snooze Quit: Changing server
1207293981 M * squat Hi, is there a release date for a updated vserver patch?
1207294075 M * daniel_hozac hmm?
1207294088 M * squat for 2.6.24 or newer?
1207294132 M * daniel_hozac there are experimental patches available, but they're not feature complete.
1207294146 M * daniel_hozac as to when they will be, that's a matter of man-hours.
1207294211 M * squat is there a version control system so someone can add those features?
1207294223 M * daniel_hozac just upload patches.
1207294247 M * daniel_hozac (and paste the links)
1207294250 M * squat and what features are missing at this time?
1207294310 M * daniel_hozac 32-bit compat, CPU scheduler, pid space support, etc.
1207294323 M * daniel_hozac and a lot of things still need testing.
1207294429 M * squat thats not good to hear
1207294467 Q * balbir_ Read error: Operation timed out
1207294513 N * DoberMann[ZZZzzz] DoberMann
1207294542 M * pmjdebruijn squat: oh well, the openvz folks are still stuck at 2.6.18 for their last stable patch
1207294888 M * squat so your project does not intend to part of debian/lenny? i believe they do a feature freeze in 1-2 months, and try to ship a 2.6.24er kernel
1207294903 M * squat and .. 
1207294904 M * squat :-)
1207294915 M * squat thanks for listening i'm just worried
1207294924 M * squat so bye bye until later the day
1207295695 J * balbir ~balbir@122.167.203.247
1207295771 N * ensc Guest539
1207295771 Q * Guest539 Read error: Connection reset by peer
1207295780 J * ensc ~irc-ensc@77.235.182.26
1207295886 M * daniel_hozac squat: Bertl_zZ would be happy to see donations so he could focus on the project...
1207296482 Q * daniel_hozac Ping timeout: 480 seconds
1207296536 Q * opuk Ping timeout: 480 seconds
1207296868 J * daniel_hozac ~daniel@ssh.hozac.com
1207296916 J * opuk ~kupo@2001:16d8:ffbd:100::10
1207297558 Q * esa Ping timeout: 480 seconds
1207297660 J * esa ~esa@ip-87-238-2-45.static.adsl.cheapnet.it
1207297902 J * dna ~dna@82-216-dsl.kielnet.net
1207298015 J * friendly12345 ~friendly@ppp121-44-224-29.lns2.mel4.internode.on.net
1207298031 Q * fatgoose Quit: fatgoose
1207298245 J * JonB ~NoSuchUse@130.227.63.19
1207298607 J * balbir_ ~balbir@122.167.176.80
1207298977 Q * balbir Ping timeout: 480 seconds
1207301343 Q * nkukard Ping timeout: 480 seconds
1207301672 Q * ||Cobra|| Read error: Connection reset by peer
1207302217 Q * FireEgl Read error: Connection reset by peer
1207302223 J * nkukard ~nkukard@196.212.73.74
1207302713 J * _nkukard_ ~nkukard@196.212.73.74
1207302813 Q * nkukard Ping timeout: 480 seconds
1207302917 J * cryptronic ~oli@p54A3BD05.dip0.t-ipconnect.de
1207303045 J * FireEgl FireEgl@2001:5c0:84dc:1:4:ff:fe00:1
1207303943 Q * FireEgl Read error: No route to host
1207303963 Q * _nkukard_ Ping timeout: 480 seconds
1207304947 J * FireEgl FireEgl@adsl-61-136-153.bhm.bellsouth.net
1207306057 Q * cryptronic Quit: Leaving.
1207306123 Q * friendly12345 Quit: Leaving.
1207307677 N * Bertl_zZ Bertl_oO
1207308127 Q * xdr Ping timeout: 480 seconds
1207308245 J * ftx ~ftx@dslb-084-062-252-149.pools.arcor-ip.net
1207308679 Q * mrfree Quit: Leaving
1207310627 Q * arapaho Remote host closed the connection
1207310926 J * xdr ~xdr@gote2.39.cust.blixtvik.net
1207311425 J * virtuoso_ ~s0t0na@ppp91-122-25-50.pppoe.avangarddsl.ru
1207311768 M * ktwilight_ hm, i can't write to /dev/stdout, am using 2.2.0.6
1207311786 M * ktwilight_ ls -la /dev/stdout shows -rw-r--r--  1 root root 4137506 Apr  4 12:00 stdout
1207311837 Q * virtuoso Ping timeout: 480 seconds
1207312000 M * ktwilight_ file /dev/stdout shows /dev/stdout: ASCII text <<- i guess this isn't normal.
1207312192 J * ftx_ ~ftx@dslb-084-062-229-170.pools.arcor-ip.net
1207312244 M * PowerKe Odd, I only have it in one of my vservers (gentoo, baselayout-2), the others seem fine without it
1207312268 M * ktwilight_ strange
1207312276 M * PowerKe On the vserver that has it, it's a symlink to /dev/fd/1 which is a symlink to /dev/pts/17 which is mknod 17 c 136 17
1207312286 M * ktwilight_ PowerKe, what's the output of ls -la /dev/stdout
1207312310 M * ktwilight_ PowerKe, is that the host?
1207312313 M * PowerKe Guest
1207312319 M * PowerKe lrwxrwxrwx 1 root root 4 Mar 12 23:35 /dev/stdout -> fd/1
1207312329 M * PowerKe lrwx------ 1 root root 64 Apr  4 14:32 /dev/fd/1 -> /dev/pts/17
1207312342 M * PowerKe crw--w---- 1 root tty 136, 17 Apr  4 14:32 /dev/pts/17
1207312379 M * ktwilight_ hm, i don't have fd/1 nor pts/17
1207312394 M * ktwilight_ i have pts/13 14 15 16 20 and 5
1207312552 M * PowerKe Anyway, not being able to write to it probably means you're trying to write to it as non-root user?
1207312572 Q * ftx Ping timeout: 480 seconds
1207312604 M * ktwilight_ i'm root.
1207312652 M * PowerKe Odd, since in your case it's a regular file...
1207312694 M * ktwilight_ 'xactly.
1207312701 M * ktwilight_ no bugs filed in debian either.
1207312827 M * ktwilight_ ok, so ln -s /proc/self/fd/1 /dev/stdout fixed it
1207315134 N * ensc Guest560
1207315134 Q * Guest560 Read error: Connection reset by peer
1207315143 J * ensc ~irc-ensc@77.235.182.26
1207315227 J * brag ~bragon@2001:7a8:aa58::1
1207315229 M * brag hug
1207315942 J * fatgoose ~samuel@76-10-149-199.dsl.teksavvy.com
1207315974 J * fatgoose_ ~samuel@76-10-149-199.dsl.teksavvy.com
1207315975 Q * fatgoose Read error: Connection reset by peer
1207316128 M * squat daniel_hozac: if Bertl could do more than one release in a year, people would more likely donate, its hard to donate to a project without a proper state, todo, bugtracking, version control, so nobody knows how far the next release is
1207316165 M * sid3windr then again more donation would probably increase the chance of those things happening ;)
1207316176 J * _gh_ ~gerrit@c-67-169-199-103.hsd1.or.comcast.net
1207316437 M * daniel_hozac squat: we've all got bills to pay. porting to new kernels is a _lot_ of effort.
1207316512 M * daniel_hozac (especially when the CPU scheduler changes, mainline adds new half-finished virtualization spaces, etc.)
1207316548 Q * mcp Remote host closed the connection
1207316563 J * mcp ~hightower@wolk-project.de
1207316662 M * squat daniel_hozac: true, everyone needs money, that is only one reason more to make the projekt more transparent to others
1207316708 M * JonB print them yourself
1207316808 M * daniel_hozac how could it be more transparent?
1207316845 M * daniel_hozac as soon as a new patch is created, it gets uploaded.
1207317540 M * sid3windr well, that's easy
1207317545 M * sid3windr provide insight into why there is no new patch yet :)
1207317583 M * daniel_hozac i thought that was implied. not enough man-hours.
1207317940 M * sid3windr well, that's not the transparancy squat means I guess
1207317946 M * sid3windr i.e. where the manhours are going/need to go
1207317963 M * sid3windr -> why is there no new patch -> no time, no time for what -> kernel has idiotic scheduler change
1207317967 M * sid3windr or so.
1207317983 M * sid3windr or what is blocking 2.x.y release: v6 not working properly, broken on 64bit, etc
1207317986 M * sid3windr [or so]
1207318600 M * Bertl_oO sid3windr, squat: folks are good in complaining, not in doing, eh?
1207318612 M * sid3windr :]
1207318615 A * sid3windr isn't complaining :)
1207318637 M * sid3windr just saying that I think what squat means
1207318652 M * sid3windr and somewhere hoping that squat is saying what he is because he wants to donate :]
1207318670 A * sid3windr is using vserver for 4-5 years now and has always been happy
1207318670 N * Bertl_oO Bertl
1207318690 M * sid3windr and I don't mind running devel releases, though it bit me in the a** once when sendfile got broken ;)
1207318803 J * dowdle ~dowdle@71-221-12-221.blng.qwest.net
1207318889 Q * Aiken Remote host closed the connection
1207319497 J * Julius ~julius@p57B2650E.dip.t-dialin.net
1207319790 M * Bertl nap attack .... bbl
1207319797 N * Bertl Bertl_zZ
1207320827 Q * Slydder Quit: Leaving.
1207321914 J * nkukard ~nkukard@vc-196-207-35-48.3g.vodacom.co.za
1207322177 J * cryptronic ~oli@p54A3BD05.dip0.t-ipconnect.de
1207322456 Q * balbir_ Read error: Operation timed out
1207322657 J * hparker ~hparker@linux.homershut.net
1207323088 Q * nkukard Read error: Connection reset by peer
1207323439 Q * meebey Remote host closed the connection
1207323463 J * nkukard ~nkukard@vc-196-207-35-48.3g.vodacom.co.za
1207323492 Q * JonB Quit: This computer has gone to sleep
1207323862 Q * xdr Ping timeout: 480 seconds
1207324083 Q * eyck Ping timeout: 480 seconds
1207324549 J * julius_ ~julius@p57B25AB4.dip.t-dialin.net
1207324679 J * eyck TOBWrAgv@nat06.nowanet.pl
1207324982 Q * Julius Ping timeout: 480 seconds
1207325098 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1207325622 Q * dowdle Remote host closed the connection
1207326259 Q * _gh_ Ping timeout: 480 seconds
1207327090 M * yarihm i've a question regarding memory-limits. We sell vservers to customers and often run into the following issue: without settings limits, one or few contexts use all of the physical memory for their stuff, all others' processes get slow (because they are swapped out). When setting limits, these apply to global memory (i.e. memory and swap), so if i set a limit of 512MB this includes swap _and_ physical memory. Is there a way to assign say 512MB physical
1207327090 M * yarihm  RAM (fixed, no overbooking needed there) to a context after which processes begin to swap?
1207327167 M * yarihm or in other words: can I set a limit on the physical RAM only? contexts may swap but physical memory must be limited. otherwise we run into the issue that some users use all of the physical memory while others get nothing
1207327209 M * ard as far as I know, you can set physical limits, after which the kernel start shooting processes down....
1207327246 M * ard and with soft limits you can advice which vserver should be allowed more memory, if there is a memory shortage
1207327316 M * ard so, you should set hard limits to limit the total virtual memory used, and set soft limits to advice which vserver is allowed to use more, when the memory pool gets drained
1207327351 M * ard but there is no setting that keeps a hard limit on the amount of RAM used per vserver
1207327407 M * ard (which would have been c00l, but probably very hard to implement)
1207327460 M * ard BTW: I haven't really used it myself. Bertl_zZ and daniel_hozac knows if what I say is correct or not ;-)
1207327541 M * ard If I look at http://www.nongnu.org/util-vserver/doc/conf/configuration.html, there is a resource.hard, a .soft, but also a .min, maybe that's what you want :-)
1207327579 M * ard you have probably read http://linux-vserver.org/Memory_Limits already
1207327601 M * yarihm ard, thanks for the hint ... let me test that. if the rss.soft is used as an advice for the scheduler, then that might be useful. but not so much if it ignores the advice.
1207327614 M * yarihm ard, yeah, read that one about memory limits
1207327639 M * ard I know the hard limit works pretty well 8-D
1207327654 M * ard but in my case usually the processes play nice...
1207327696 M * ard and for my hobby company, I always say: "well, it's more of a hobby, no garantuees"
1207327782 M * yarihm ard, yes, they do, the processes are killed when hitting the limit. that's actually also not what you'd want for a hosting environment
1207327814 M * yarihm ard, well, for my own stuff that holds, too. but the ISP I am working for has a different view of things :)
1207327866 M * ard Heh, the "ISP" I am working for already writes the software that's running in it :-)
1207327887 M * ard The ISP<->client thing is at most a department away 8-D
1207328085 M * yarihm the min-thing might actually work. i could set "hard" to say 2GB, "soft" to say 0.5 GB and "min" to 0.5GB such that display in top and behaviour of the server (hopefully) match
1207328234 M * daniel_hozac min is not implemented.
1207328250 M * daniel_hozac implementing that is _really_ difficult, and typically not what you want either way.
1207328377 J * balbir ~balbir@122.167.179.223
1207328411 M * yarihm daniel_hozac, ah ... what a pitty.
1207328532 M * yarihm daniel_hozac, so, what would you recommend for a hosting company that offers vservers? we don't need to overbook the physical memory, we just need to ensure that on one steals memory from someone else. setting the hard-limit to TOTAL-MEM/#CONTEXTS is not an option, swapping should be allowed, otherwise the offer is either too bad for the customer or too expensive for the operator
1207328632 M * yarihm we can set the hard-limit to TOTAL-MEM/#CONTEXTS + FOOBAR, but then how to ensure that for another context the physical memory is not just TOTAL-MEM/#CONTEXTS - FOOBAR while the other guy uses too much of the physical memory
1207328658 M * yarihm maybe Bertl_zZ knows?
1207328836 M * daniel_hozac you can't really _guarantee_ it.
1207328918 M * yarihm ok, i do not need real hard guarantees, but somehow it must be possible to share the memory fairly amongst the context, not on a "first come, first serve" or on a "most greedy, most successful" base, no?
1207328955 M * daniel_hozac using soft limits is probably your best bet.
1207328974 M * yarihm is the scheduler taking these into account?
1207328982 M * daniel_hozac i don't think it is, yet.
1207328986 J * xdr ~xdr@gote2.183.cust.blixtvik.net
1207328998 M * daniel_hozac that wouldn't be very difficult to add though.
1207328999 M * yarihm so what good is it setting them?
1207329025 M * daniel_hozac IIRC it increases the odds of processes in guests which are over the limit to get OOM-killed.
1207329047 M * yarihm i see ...
1207329120 M * yarihm well, adding that feature (the scheduler or virt-mem-ruler taking these limits into account) would be a hell of a feature for people running vservers in shared environments
1207329269 M * yarihm this is becoming a real issue here as all our stuff runs on linux-vserver. there are people stating that this would be mitigated with openvz which I for several reasons don't like that much. such a migration costs something though, so depending on how easy implementing this is, it might be worth investing the money to fund Bertl to do it instead of investing the money for a migration. I'll check on this
1207329329 M * yarihm that'd be a win-win-situation (I hope?). do you guys do things like this? coding or implementing for money?
1207329359 Q * ftx_ Remote host closed the connection
1207329393 M * yarihm OTOH I guess you have had that offer a lot without any backing, so I shouldn't talk too much
1207329411 J * JonB ~NoSuchUse@77.75.164.169
1207329451 N * ensc Guest580
1207329451 Q * Guest580 Read error: Connection reset by peer
1207329461 J * ensc ~irc-ensc@77.235.182.26
1207329634 J * _gh_ ~gerrit@bi01p1.co.us.ibm.com
1207329657 Q * xdr Remote host closed the connection
1207329669 J * xdr ~xdr@gote2.183.cust.blixtvik.net
1207330134 Q * _gh_ Ping timeout: 480 seconds
1207330834 J * _gh_ ~gerrit@bi01p1.co.us.ibm.com
1207331196 J * hijacker ~Lame@87-126-142-51.btc-net.bg
1207331334 Q * _gh_ Ping timeout: 480 seconds
1207331524 J * Genghis genghis@78-23-99-209.access.telenet.be
1207331524 N * Genghis Guest586
1207331534 N * Guest586 Genghis-
1207331537 M * yarihm gotta go, cu later guys
1207331539 Q * yarihm Quit: Leaving
1207332938 J * _gh_ ~gerrit@bi01p1.co.us.ibm.com
1207333125 N * Bertl_zZ Bertl
1207333129 M * Bertl back now ...
1207333155 M * JonB hey be
1207333156 M * JonB Bertl: 
1207333298 M * Bertl hey JonB!
1207334100 J * Piet ~piet@tor.noreply.org
1207334173 Q * Genghis- Remote host closed the connection
1207334373 J * Genghis- ~Genghis@got.debian-inside.com
1207334396 Q * nkukard Quit: Leaving
1207335176 N * Genghis- Genghis
1207335213 N * Genghis Guest592
1207335356 J * doener ~doener@i577BB809.versanet.de
1207335550 Q * hijacker Quit: Leaving
1207335723 Q * doener_ Read error: Connection reset by peer
1207336824 Q * JonB Quit: This computer has gone to sleep
1207337165 Q * Piet Remote host closed the connection
1207337263 J * Piet ~piet@tor.noreply.org
1207337439 Q * FireEgl Ping timeout: 480 seconds
1207338836 N * Guest592 Genghis
1207338873 N * Genghis Guest596
1207338956 J * JonB ~NoSuchUse@77.75.164.169
1207339669 Q * hparker Quit: Read error: 104 (Peer reset by connection)
1207339765 Q * ktwilight_ Quit: dead
1207339875 Q * _gh_ Ping timeout: 480 seconds
1207340614 J * _gh_ ~gerrit@bi01p1.co.us.ibm.com
1207341073 M * trippeh Is oops'es in generic_setlease() (something VFS-related, it seems) a known problem in 2.6.24-vs2.3.0.34?
1207341086 M * trippeh (Yes, I know this version is probably incomplete)
1207341412 M * Bertl 2.6.24 or 2.6.24.4?
1207341432 M * Bertl and do you have a kernel trace for me to look at?
1207341443 M * trippeh Err, 2.6.24.4
1207341561 M * trippeh Bertl: Hold on
1207341586 M * trippeh I havn't completely fingered it on vserver though, just seems likely as 2.6.24.4 has been stable otherwise to date.
1207341736 N * BobR_oO BobR
1207341740 N * DoberMann DoberMann[PullA]
1207341920 M * trippeh It seems to crash when samba accesses a file, on the host, as long as vserver is enabled, but happens with no guests booted yet.
1207341923 M * trippeh Bertl: http://paste.linux-vserver.org/11900
1207341967 A * trippeh boots a vanilla kernel to be sure
1207342112 M * trippeh Ok, so that works.
1207342255 M * Bertl do you have the kernel sources at hand?
1207342266 M * Bertl (from the vserver kernel, that is)
1207342319 M * trippeh I can reconstruct an exact copy from the package build
1207342379 M * Bertl okay, please do that and get me the lin numbers for the trace
1207342383 M * Bertl (with addr2line)
1207342496 N * Guest596 Genghis
1207342533 N * Genghis Guest599
1207342537 M * trippeh ..I which bzip2 was multithreaded :)
1207342541 M * trippeh wish even
1207342601 M * Bertl you know, that would be possible
1207342786 N * BobR BobR_zZ
1207342787 M * trippeh It takes longer to bzip2 it than transferring it over the internet to home
1207342818 M * Bertl yes, that is what gzip --fast is for :)
1207342835 M * Bertl (preferably in the transfer stream)
1207342947 M * trippeh addr2line: /boot/vmlinuz-2.6.24-1-vs: File format not recognized
1207342955 M * trippeh I need the vmlinux file?
1207343117 M * trippeh *hugs ccache*
1207343498 M * Bertl yep, bzImage won't work
1207343527 J * dowdle ~dowdle@71-221-12-221.blng.qwest.net
1207343577 M * trippeh Grrr, addr2line doesn't handle relocatable kernels
1207343583 M * trippeh In this binutils version
1207343714 M * trippeh Wait, thats off.
1207343723 M * trippeh Something is not right then, it just returns ?? :-P
1207343844 Q * bonbons Quit: Leaving
1207344090 M * Bertl maybe you disabled kernel debug/info?
1207344105 M * Bertl if so, please recompile with that (and vserver debugging) on
1207344118 M * Bertl and let's get a new kernel trace (addresses will change)
1207344683 M * trippeh D'oh. Recompiling. I'll be out for a few minutes to get something to eat while it is doing its thing
1207345166 M * Bertl np
1207345533 J * ritter__ ~lownoize@p5B07698C.dip.t-dialin.net
1207345978 Q * ritter_ Ping timeout: 480 seconds
1207346143 Q * xdr Ping timeout: 480 seconds
1207346157 N * Guest599 Genghis
1207346194 N * Genghis Guest605
1207346323 Q * _gh_ Ping timeout: 480 seconds
1207346488 J * dna_ ~dna@82-216-dsl.kielnet.net
1207346869 Q * dna Ping timeout: 480 seconds
1207347176 Q * JonB Quit: This computer has gone to sleep
1207347253 M * trippeh Booting..
1207347508 Q * transacid Remote host closed the connection
1207347530 J * transacid ~transacid@transacid.de
1207347734 J * xdr ~xdr@224-173-96-87.cust.blixtvik.se
1207347744 Q * julius_ Remote host closed the connection
1207347785 J * mire ~mire@162-174-222-85.adsl.verat.net
1207347934 J * Aiken ~james@ppp121-45-192-61.lns1.bne1.internode.on.net
1207348034 M * trippeh Bertl: http://paste.linux-vserver.org/11901
1207348047 M * trippeh Manualy resolved... Hope it didn't get too messy :)
1207348063 M * trippeh I can put the source tarball with .config on the internets, if needed
1207348120 N * DoberMann[PullA] DoberMann[ZZZzzz]
1207348171 M * Bertl hmm, no, that seems to be a lock without a file .. strange
1207348224 M * trippeh Noticed it touched a cowbl code path
1207348236 M * Bertl please try to change the line from:
1207348239 M * Bertl         vx_locks_inc(fl);
1207348242 M * Bertl to 
1207348249 M * Bertl         vx_locks_inc(new_fl);
1207348332 Q * dna_ Quit: Verlassend
1207348730 J * snooze ~o@1-1-4-40a.gkp.gbg.bostream.se
1207348797 M * trippeh Loading a DEBUG_INFO initramfs off flash storage takes a bit of time :P
1207348873 M * trippeh Bertl: Yay, no OOPS yet.
1207348892 M * trippeh 10 files opened and counting, used to crash after 1-2 ;)
1207349011 Q * doener Quit: leaving
1207349120 M * Bertl okay, looks good to me too, added that to my tree, so it will be in the next uploaded version.
1207349128 M * Bertl thanks a lot for reporting and testing!
1207349154 M * Bertl let me know if you encounter any other issues (or if this one comes up again)
1207349170 M * trippeh Yeah. :)
1207349196 M * Bertl off to bed now ... probably won't be too long (not sleeping too well at night :)
1207349197 M * trippeh Anything missing in the 2.4.24.4-vs tree btw? Besides testing :)
1207349229 M * Bertl yes, scheduler support, various filesystems and some capability stuff
1207349238 N * Bertl Bertl_zZ
1207349251 M * trippeh Ah. I'm covered then :)
1207349557 J * nkukard ~nkukard@196.212.73.74
1207349818 N * Guest605 Genghis
1207349853 N * Genghis Guest612
1207353477 N * Guest612 Genghis
1207353486 Q * hardwire Read error: Connection reset by peer
1207353513 N * Genghis Guest615
1207353525 J * hardwire ~bip@xvm-189-205.ghst.net