1501208152 Q * Ghislain Quit: Leaving. 1501211521 Q * _are_ Ping timeout: 480 seconds 1501211541 J * fstd_ ~fstd@x4db5ca58.dyn.telefonica.de 1501211561 J * _are_ ~quassel@2a01:238:4325:ca00:f065:c93c:f967:9285 1501212011 Q * fstd Ping timeout: 480 seconds 1501212011 N * fstd_ fstd 1501221442 J * sannes ~ace@2a02:fe0:c130:1d90:1c62:d6b4:3b14:6d70 1501224683 J * Ghislain ~ghislain@81.56.195.31 1501226769 Q * gnarface Remote host closed the connection 1501227782 Q * fosco_ magnet.oftc.net resistance.oftc.net 1501227804 J * fosco_ fosco@marx.wirefull.org 1501227855 J * gnarface ~gnarface@108-227-52-42.lightspeed.irvnca.sbcglobal.net 1501229113 J * Gremble ~Gremble@cpc87179-aztw31-2-0-cust6.18-1.cable.virginm.net 1501229591 M * gnarface so uh 1501229606 M * gnarface which patch version should i use? 1501229928 N * Bertl_zZ Bertl 1501229930 M * Bertl morning folks! 1501229947 M * Bertl gnarface: what kernel do you use? 1501229965 M * gnarface morning Bertl, i'm setting up a new server so i'm trying to decide what version to use 1501229990 M * gnarface kernel and patch version 1501230100 M * gnarface so the last one i set up used patch-3.14.52-vs2.3.6.15.diff i think 1501230110 M * gnarface but now kernel 3.16 is in devuan stable 1501230137 M * gnarface so i'm wondering if it would be better to use patch-3.18.55-vs2.3.7.5.diff instead 1501230187 M * gnarface i was also considering the 4.x patches 1501230207 M * gnarface not sure if it's worth it 1501230600 M * gnarface but i could compile from a vanilla kernel instead of patching a distro kernel, so it doesn't have to be any specific version 1501230625 M * gnarface just compatible with jessie i guess 1501231036 M * Gremble Use our repos if you like gnarface http://repo.psand.net/ 1501231062 M * Bertl gnarface: what about 4.1.x? 1501231083 M * gnarface thanks for the offer Gremble but i'm keen to compile it myself 1501231108 M * gnarface Bertl: should i just use patch-4.1.42-vs2.3.8.6.diff and a vanilla 4.1.42 kernel then? 1501231158 M * gnarface stability and security are most important, but performance wouldn't be shunned 1501231182 M * gnarface testing is using kernel 4.9 so future-proofing isn't really on the table 1501231203 M * Bertl 3.14 isn't really maintained anymore 1501231212 M * gnarface hmm. noted 1501231213 M * Bertl 3.18 is EOL 1501231227 M * Bertl (so probably no upstream updates) 1501231292 M * Bertl 3.10, 3.16 and 4.1 did get some upstream updates recently 1501231318 M * Bertl there are no Linux-VServer patches for 3.16 1501231331 M * Bertl so that leaves you with 3.10.x or 4.1.x 1501231418 M * Gremble Bertl, will you be updating the patch for 3.18? 1501231434 M * Bertl most likely 1501231454 M * Bertl but note that upstream will not update an EOL kernel 1501231468 M * Gremble that's most excellent that you'll probably update, it's my most used kernel 1501231502 M * Gremble sure, there's needs to be another route. I'll have to try to get 4.1 working on all my systems, find out what the errors are 1501233488 M * gnarface well i'm about to try it 1501233505 M * gnarface kernel-package is still the recommended way to build it? 1501234292 M * Bertl I built all my kernels from the source, but beng has nice repositories for debian and co IIRC 1501234355 M * gnarface i've been building my own util-vserver too, so i have one without the legacy scripts that doesn't violate the debian FHS 1501234364 M * gnarface i know it's a little OCD but that's just how i roll 1501234446 M * gnarface i guess my question was more about whether i should use make-kpkg still, or if i should be using ./debian/rules build or whatever 1501234494 M * gnarface or Bertl did you mean by that that you don't even package your installed kernels? 1501234533 M * Bertl and my answer should have been: I do not use either, I build it from source and install from the source tree :) 1501234546 M * gnarface just like "make install" really? 1501234560 M * gnarface you maverick you 1501234566 M * Bertl and modules_install for non monolithic kernels, yes :) 1501237838 J * aj_ ~aj@b2b-94-79-172-98.unitymedia.biz 1501238851 M * gnarface which util-vserver version should i use with this kernel then? with 4.1.42? 1501239370 M * gnarface this one? util-vserver-0.30.215.tar.bz2 1501239540 M * Bertl I'd go for one of the testing versions, preferably the latest 1501240125 M * gnarface util-vserver-0.30.216-pre3126.tar.gz? 1501240166 M * Bertl sounds good 1501240487 M * gnarface ok, thanks 1501245966 M * gnarface oh no 1501245970 M * gnarface it builds several packages 1501245973 M * gnarface which one do i install? 1501245980 M * gnarface util-vserver-sysv_0.30.216-pre3126-1_amd64.deb ? 1501245986 M * gnarface util-vserver-build_0.30.216-pre3126-1_amd64.deb ? 1501245991 M * gnarface util-vserver-core_0.30.216-pre3126-1_amd64.deb ? 1501246054 M * gnarface should i just use the util-vserver from the jessie repo? it's 0.30.216-pre3054 1501246363 M * AlexanderS gnarface: -core is the core, -build contains the parts of util-vserver for building new guests, and -sysv contains the init.d Scripts. 1501246387 M * gnarface AlexanderS: i see. util-vserver_0.30.216-pre3126-1_amd64.deb is just all of it then in one package? 1501246409 M * gnarface AlexanderS: or do i need to install all of them? 1501246482 M * AlexanderS gnarface: I have installed all. 1501246534 M * AlexanderS util-vserver depends on util-vserver-core and util-vserver-sysv on my host. 1501246555 M * gnarface ah, so it does 1501246560 M * gnarface maybe i can leave legacy out though 1501246651 M * gnarface AlexanderS: i forget, does it matter if i build and install util-vserver first, or do i have to boot the vserver kernel before it's safe to install util-vserver? 1501246695 M * AlexanderS gnarface: Installation shouldn't be problematic. 1501247025 M * gnarface i changed /vservers to /var/lib/vservers, and i note that on installation the packages still setup /vservers 1501247026 M * gnarface :( 1501247034 M * gnarface then complain about it (because i didn't boot the kernel yet, i guess) 1501247051 M * gnarface i feel like this happened with the last server and i just recreated the directories by hand 1501248298 M * gnarface do i still need to set the chroot barrier flag on the /vserver directory? not any more, right? 1501248388 M * Bertl the necessity of the barrier is unclear with recent kernels 1501248395 M * Bertl s/of/for 1501248472 M * gnarface hmm 1501248476 M * gnarface so i should enable it to be sure? 1501249655 M * gnarface hmmm. argh, does xfs not support the barrier? 1501249668 M * gnarface or am i checking it wrong? 1501249957 M * gnarface hmm. manpage says they are enabled by default. 1501250386 M * gnarface but i don't see the "B" just "b" 1501250844 M * Bertl XFS has no barrier support 1501250860 M * gnarface doh 1501250906 M * gnarface oh, the barriers i see in the man page mentioned as "block layer write barriers" are not the same thing? 1501250959 M * gnarface well shoot i guess so much for xfs on my new vserver host 1501251182 M * Bertl as I said, it's not sure that you need them at all, so unless you want other filesystem features like unification, it's probably safe to use XFS 1501251216 M * gnarface hmm. ok 1501252263 M * gnarface Bertl: what filesystem do you use these days? 1501252276 M * Bertl ext3 and in some cases ext4 1501252298 M * Bertl off for now ... bbl 1501252299 N * Bertl Bertl_oO 1501252860 Q * Gremble Quit: Leaving 1501252868 M * gnarface completely, unrelated, does anyone know why i disabled "CONFIG_SCHED_SMT" on the last vserver kernel i built? the kernel help only says it's for pentium4's, but that should work on Phenom II processors too, shouldn't it? 1501253127 M * Guy- isn't this the option that adds hyperthreading support/awareness to the scheduler? 1501253163 M * Guy- gnarface: and yes, those xfs barriers are a different thing 1501253181 M * Guy- (they're a mechanism to prevent the storage backend from reordering certain writes) 1501253331 M * gnarface yea that's the symmetric multi threading flag 1501253410 M * gnarface SMT (Hyperthreading) scheduler support 1501253429 M * gnarface i noticed it was disabled in the other server's kernel config 1501253442 M * gnarface but it's on by default in this vanilla source for 4.1.42 1501253451 M * gnarface despite that the help says if unsure say N 1501253465 M * gnarface maybe that's why i unchecked it on the last one 1501255013 M * Guy- I tend to enable it, but I don't have measurements to back me up 1501255524 M * gnarface ah i think i found a legit explanation here https://www.techpowerup.com/forums/threads/does-the-phenom-ii-have-hyper-threading.116405/ 1501255548 M * gnarface i got hyper transport confused with hyper threading 1501256591 M * gnarface i keep doing that 1501256596 M * gnarface argh 1501258432 Q * aj_ Ping timeout: 480 seconds 1501267023 J * aj_ ~aj@p2003008E6C271700214F750ED70783A2.dip0.t-ipconnect.de 1501274640 Q * Aiken Remote host closed the connection 1501274916 J * Aiken ~Aiken@d63f.h.jbmb.net 1501279788 Q * Defaultti Quit: WeeChat . 1501279858 J * Defaultti defaultti@lakka.kapsi.fi