| 00:04.22 | *** join/#devuan absinthe (~absinthe@unaffiliated/absinthe) |
| 00:11.15 | *** join/#devuan Xenguy (~Xenguy@devuan/community/Xenguy) |
| 00:26.28 | systemdlete | Interesting. After hours and hours -- no, really, days! -- of fighting with this, I have discovered something. I'm on ascii with kernel 4.9.0-13 and I could not add a partition on a new disk (same size) to an existing array running on two existing disks, BUT |
| 00:27.55 | systemdlete | I can create a NEW array with the same partition on the new disk (forcing a single member) and then add one of the partitions of the existing array (after removing it first) to the new array. |
| 00:29.30 | systemdlete | In the first (more normal I think) scenario, the kern.log gets flooded with all kinds of nasty messages from the disk driver and the system honks every so often. |
| 00:29.55 | systemdlete | In the 2nd scenario, nothing bad happens. In both scenarios, the array gets sync'd though. |
| 00:30.15 | systemdlete | ???? |
| 00:33.15 | systemdlete | btw, I'm using the mdadm tools (not mdraid, just to be clear) |
| 00:33.42 | systemdlete | also, all of my raids are level 1 and are at version 1.2 |
| 00:34.25 | systemdlete | I should also clarify that I can indeed, "add" the partition in both cases, but in the first case, I get all kinds of horrible noise and errors. |
| 00:34.48 | gnarface | so are you suspecting a bug in the harddrive controller? |
| 00:34.57 | gnarface | in the driver for the harddrive controller, i mean? |
| 00:35.01 | systemdlete | why? |
| 00:35.13 | gnarface | i'm asking you if that's what you're saying |
| 00:35.27 | systemdlete | If it were REALLY, TRULY, a hardware controller or disk issue, I'd expect the errors to occur in either scenario. |
| 00:35.30 | systemdlete | right? |
| 00:35.46 | systemdlete | oh, you mean the kernel code |
| 00:35.48 | gnarface | hmmm... they're the same models of disks? |
| 00:35.51 | systemdlete | no |
| 00:35.56 | gnarface | yea, i mean in the kernel code |
| 00:36.01 | systemdlete | I purposely do NOT use the same models |
| 00:36.03 | gnarface | maybe a regression |
| 00:36.10 | systemdlete | Let me give you the layout |
| 00:36.26 | gnarface | or, well, maybe it's been fixed by now. they're well past version 4.9 |
| 00:36.42 | systemdlete | I am feeling great pressure to move on to beowulf. |
| 00:37.19 | systemdlete | the sync (2nd scenario) just finished. no issues. |
| 00:37.24 | *** join/#devuan Inepu (~Mithrandi@46.234.217.137) |
| 00:37.49 | systemdlete | but I am going to give the new array some "work" to do. |
| 00:38.05 | systemdlete | Just to see if there might be some actual problems w h/w, etc |
| 00:39.31 | gnarface | good idea |
| 00:39.49 | systemdlete | I just found "iometer" I will try that |
| 00:39.59 | systemdlete | iogen also |
| 00:39.59 | gnarface | also, even if you don't want to go to beowulf yet, you might still be able to try the ascii-backports kernel, which i think is similar in version |
| 00:40.37 | gnarface | it's not a guarantee that there's a problem with the kernel, but it seems highly plausible |
| 00:43.36 | systemdlete | neither iometer nor iogen are available in the repo, but I found fio, which I think does similar |
| 00:44.19 | systemdlete | (I agree. It has to be the kernel, since it is pretty clear it is NOT the new disk, or the old ones for that matter) |
| 00:45.30 | *** join/#devuan arnoldoree (~arnoldore@113.210.97.10) |
| 00:46.09 | gnarface | well, could be the harddrive controller itself, but usually when they go they don't get subtly flaky like this. that's possible, but rare. usually they either die completely, or at least individual ports die completely while the rest works fine. |
| 00:46.57 | gnarface | kernel regressions on rare old hardware that shares drivers with vast swathes of common new hardware though... that's common |
| 00:47.01 | systemdlete | holy cow. The man page for fio is, like, 1000 pages long. |
| 00:47.25 | systemdlete | I should study and memorize it, and then rent myself out at $50/hour to help people with file and disk i/o problems. |
| 00:47.35 | gnarface | systemdlete: you're just looking for a disk i/o meter? try iotop |
| 00:47.58 | systemdlete | I don't just want to measure gnarface; I want to put a load on the md filesystem |
| 00:48.11 | gnarface | oh, if you're using for an i/o tester though i dunno. i'd maybe try bonnie++ or just hdparm -T/hdparm -t |
| 00:48.15 | systemdlete | i.e., give it some work to do |
| 00:48.21 | gnarface | s/using/looking/ |
| 00:48.54 | gnarface | hdparm -T is more for benchmarking raw harddrive speeds, bonnie++ is for benchmarking filesystems |
| 00:49.30 | gnarface | well, harddrives too, but with filesystem action, as opposed to hdparm |
| 00:49.33 | systemdlete | speed is less the issue. What I want to do, really, (I think) is exercise i/o and hit a few "corner" cases |
| 00:49.51 | gnarface | so, one corner case i've had semi-recently is "also accessing temperature sensors at the same time" |
| 00:50.28 | gnarface | basically i had numerous issues with post 4.x kernels destabilizing on older boards but it seemed related directly to heavy disk i/o at the same time as temperature sensor polling |
| 00:50.32 | systemdlete | how did that one go for you? |
| 00:50.52 | systemdlete | I see! |
| 00:51.27 | gnarface | well i struggled with it for a long time, but after a lot of deductive testing and help from some kernel experts, i disabled the temperature polling in munin, and then disabled "C1E" power saving mode in the bios. rock solid after that. |
| 00:51.46 | gnarface | only burns about 3-5 more watts |
| 00:52.14 | systemdlete | I would guess this is somewhat mainboard-specific? |
| 00:52.42 | gnarface | yes, we ended up concluding it must have been a BIOS-level bug that was never fixed |
| 00:53.05 | systemdlete | how long ago? which hardware era? |
| 00:53.09 | gnarface | but also must never have been noticed at the time, just by luck, the old kernels didn't trip whatever problem it had |
| 00:53.37 | gnarface | pretty old now... one of the earliest Athlon64 boards |
| 00:54.18 | gnarface | and it had an onboard "marvell" brand sata/pata controller that at the time had problems with stability of it's own unless you forced the driver to limit it to PATA mode manually |
| 00:54.37 | gnarface | transitional era hardware with a lot of cursed parts i guess |
| 00:54.49 | gnarface | but maybe similar to what you have actually? |
| 00:54.56 | gnarface | not sure |
| 00:55.04 | systemdlete | yeah, I think it might be. |
| 00:55.24 | systemdlete | I originally had a Thuban x6, but I've since upgraded to a fx-8350 8x |
| 00:55.30 | gnarface | if so, actually it's a good enough reason for you to scour the bios for that "C1E" power saving setting. chances are it's not saving you much |
| 00:55.40 | systemdlete | thuban is athlon I think |
| 00:56.06 | systemdlete | I think thuban was the 6 core versions of athlon II |
| 00:56.09 | systemdlete | iirc |
| 00:56.26 | systemdlete | yeah, I was wondering about C1E actually. |
| 00:56.52 | gnarface | yea, i upgraded that board to a newer 4-core athlon64-x-II thinking maybe the old CPU was subtly but rarely damaged from power surges, but that didn't change shit, so confirmed for being a problem with the motherboard BIOS |
| 00:56.55 | systemdlete | So you think that by disabling it, maybe this issue with mdadm (see above) might dissapear itself? |
| 00:57.23 | systemdlete | which mb, if I may ask? Did you end up replacing it? |
| 00:57.28 | gnarface | yea, i think so. but for good measure i'd also disable temperature sensor polling from your logging system if you are doing that oo |
| 00:57.30 | gnarface | too* |
| 00:57.43 | gnarface | and obviously the cpufrequency governor should be set to something static |
| 00:57.48 | gnarface | don't ask for trouble |
| 00:57.58 | systemdlete | logwatch shows me some temp data. I don't think I'm runnig a temp monitor |
| 00:58.15 | systemdlete | don't overclock, etc? |
| 00:58.26 | gnarface | yea, don't overclock hehe |
| 00:58.47 | systemdlete | lol |
| 00:59.00 | systemdlete | time to order dinner... |
| 00:59.01 | gnarface | board is: ASUS M3N-HT Deluxe/HDMI (the cheaper model, the one one without the add-on heatpipe) |
| 00:59.08 | gnarface | and no, never replaced it |
| 00:59.14 | gnarface | it's there right now |
| 00:59.18 | systemdlete | I'll try bonnie++ and look at disabling the power saver |
| 01:00.49 | gnarface | purely academically, but the soundcard on that board, which i don't use, is also one of those cursed components that shares a driver with too much other hardware (snd_hda_intel) and it's been a pain in the ass for me on literally every motherboard it was pressed into |
| 01:01.08 | gnarface | not in a way that destabilizes the system though, luckily |
| 01:05.09 | gnarface | but, like the Marvell crappy sata/pata controller, it also generally had problems of the form "driver fails to correctly auto-detect the hardware, launches it in a partially functional but not stable mode" |
| 01:05.20 | gnarface | so that may be a common thread here you might want to pull |
| 01:05.37 | gnarface | especially if it turns out that board you're using has a Marvell disk controller |
| 01:06.13 | gnarface | (because flaws in that type of auto-detection have been historically sporadic across kernel versions for me) |
| 01:16.21 | *** join/#devuan ar3itrary (~hacker@v22016101923038440.bestsrv.de) |
| 01:26.53 | *** join/#devuan yanmaani (~yanmaani@gateway/tor-sasl/yanmaani) |
| 01:35.41 | systemdlete | So on my board, the lshw identifies the device as: product: SB7x0/SB8x0/SB9x0 IDE Controller [1002:439C] |
| 01:35.41 | systemdlete | vendor: Advanced Micro Devices, Inc. [AMD/ATI] [1002] |
| 01:36.39 | gnarface | that doesn't tell me anything useful, but google might |
| 01:37.44 | gnarface | looks almost identical to the SATA controller here i'm not having trouble with, but that proves nothing |
| 01:37.58 | gnarface | oh |
| 01:37.59 | gnarface | hmmm |
| 01:38.06 | gnarface | though that does bring up another idea about BIOS settings... |
| 01:38.15 | Xenguy | You crazy people, trying to run linux without the essential systemd |
| 01:38.22 | Xenguy | It boggles my mind |
| 01:38.34 | Xenguy | The imagination knows no terror |
| 01:38.43 | Xenguy | Greater than |
| 01:38.57 | Xenguy | The Mirror |
| 01:39.07 | gnarface | systemdlete: if that controller has a setting that's different for "IDE" mode and "AHCI" mode, the old advice to run it in "IDE" mode by default has been updated for modern kernels to "AHCI" mode. some BIOSes confusingly conflate RAID and AHCI modes, some don't. hard to know without consulting the manual. |
| 01:39.34 | Xenguy | Pardon me for interrupting, wrong channel |
| 01:40.26 | gnarface | systemdlete: 00:11.0 SATA controller: (for reference, not worth much, but this is the one i'm using here: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [AHCI mode] (rev 40)) |
| 01:40.28 | systemdlete | Yeah, I forgot about the AHCI/IDE biz. |
| 01:41.31 | gnarface | it can be annoying because not all motherboards handle AHCI and IDE modes equally stably, but at least most the time my experience has been that the kernel version was the biggest deciding factor in which was more stable |
| 01:42.06 | gnarface | AHCI mode might also be faster but usually in my experience not by much on these old boards, because we were already so close to the max throughput on the drives for that bus |
| 01:44.26 | systemdlete | looks like it is setting to AHCI mode. |
| 01:44.52 | gnarface | alright. i wonder why mine shows that in the lspci identity and yours doesn't though |
| 01:44.58 | gnarface | maybe not important |
| 01:46.10 | systemdlete | product: SB7x0/SB8x0/SB9x0 IDE Controller [1002:439C] |
| 01:46.10 | systemdlete | vendor: Advanced Micro Devices, Inc. [AMD/ATI] [1002] |
| 01:46.22 | systemdlete | 00:11.0 SATA controller: Advanced Micro Devices, Inc. [AMD/ATI] SB7x0/SB8x0/SB9x0 SATA Controller [IDE mode] |
| 01:46.28 | systemdlete | strange. |
| 01:46.45 | systemdlete | the kern.log shows it as being AHCI mode |
| 01:46.51 | gnarface | oh, yes, strange indeed. so it does say it, but it's clearly claiming IDE mode. yea that's weird. |
| 01:46.53 | systemdlete | but lspci shows it as AHCI |
| 01:47.03 | gnarface | lspci shows it as IDE you mean |
| 01:47.16 | gnarface | i don't know what's up with that, we're getting beyond my depth here |
| 01:47.23 | systemdlete | kernel: [ 0.432594] pci 0000:00:11.0: set SATA to AHCI mode |
| 01:47.36 | systemdlete | and my depth as well |
| 01:47.55 | gnarface | anything in the log about it setting it back later in the boot up maybe? |
| 01:48.31 | systemdlete | I did not see that, but it is possible I guess. Does it do that? |
| 01:48.50 | gnarface | dunno. it's news to me it can change it to AHCI mode |
| 01:49.12 | systemdlete | even so... with all of this said, gnarface |
| 01:49.22 | systemdlete | it should work either way |
| 01:49.33 | systemdlete | this is an ASUS mb, btw |
| 01:49.44 | systemdlete | and, really, I have had few issues with it. |
| 01:49.46 | gnarface | yea, it should work either way. sometimes it's not fair though. |
| 01:49.50 | gnarface | i like ASUS |
| 01:50.02 | gnarface | it's got the newest BIOS, right? |
| 01:50.05 | systemdlete | the main one seems to be that the USB 3 slots cause some harm to the system |
| 01:50.16 | gnarface | harm? like heating? |
| 01:50.20 | gnarface | or like stability problems? |
| 01:50.22 | systemdlete | (oh yeah. Last update was a few years back, and there havent been new ones since) |
| 01:50.40 | systemdlete | stability of the USB |
| 01:50.50 | gnarface | hmm, that's less weird. |
| 01:50.57 | gnarface | usb3 is still not really done |
| 01:51.13 | systemdlete | I pulled the 2 usb3 devices from the 2 usb3 ports and put them in usb2 ports |
| 01:51.56 | *** join/#devuan Xenguy (~Xenguy@devuan/community/Xenguy) |
| 01:52.09 | *** join/#devuan pekman (~pekman@unaffiliated/pekman) |
| 01:52.17 | systemdlete | the devices work ok, because neither of them are actually requiring usb3 speeds. One is a wireless device I am using as an WAP and the other is an ethernet dongle |
| 01:52.52 | systemdlete | my comcast here is <100Mbps; I think you need usb3 for 1000Mbps |
| 01:53.27 | systemdlete | although now -- get this -- comcast is forcing me to switch plans. I'll be paying $10 less and I will get up to 200mbps and some tv! |
| 01:53.33 | systemdlete | ???? wtf? |
| 01:54.01 | gnarface | then they sneak into your house at night and steal a kidney |
| 01:54.20 | gnarface | not really a support issue, but i would advise you do anything possible to use any other ISP |
| 01:54.36 | gnarface | i know the savings can be hard to shrug off though |
| 01:54.38 | systemdlete | comcast, charter, century cox, and the rest of the c-words should be dissolved and replaced with net-neutral publicly-owned and operated Internet. But we are getting O.T. here |
| 01:54.57 | gnarface | so, one thing comes to mind about the USB thing but it's vague |
| 01:55.15 | gnarface | there were once two usb drivers, and they supported separate hardware |
| 01:55.25 | systemdlete | Well, AT&T offers actual HSI these days (I think they run fiber in the streets) so it is no longer dialup or DSL |
| 01:55.33 | Xenguy | re: C's: Amen |
| 01:55.42 | systemdlete | heheh, Xenguy |
| 01:55.43 | gnarface | ... and then at some point one of those usb drivers took over for the other i think, in some cases? |
| 01:55.48 | Xenguy | Represent! |
| 01:55.51 | DonkeyHotei | at&t in most places is still VDSL |
| 01:56.13 | gnarface | anyway, it was for speed, but mabye that's to do with your usb3 issue, systemdlete... maybe there's a driver choice you can change back to the legacy one. not sure about that, but worth looking into. |
| 01:57.03 | systemdlete | maybe. When I had the usb3 ports in use, my kern.log was filling up with warnings about something or other. |
| 01:57.09 | gnarface | VSDL is fibre to the phone-pole, though from what i can tell they only let you use it for the download direction |
| 01:57.17 | systemdlete | those are gone now, but I still get some noise from that corner. |
| 01:57.54 | gnarface | systemdlete: something about ohci, ehci... uhci... xhci??? i dunno |
| 01:57.54 | *** join/#devuan onefang (~onefang@devuan/developer/onefang) |
| 01:58.19 | gnarface | systemdlete: i remember reading it as errata at the time but i got lucky and never ran into any troubles due to the change |
| 01:58.50 | systemdlete | reset high-speed USB device number 12 using ehci-pci |
| 01:59.02 | systemdlete | or similar |
| 01:59.20 | *** join/#devuan fncapkle (~fncapkle@184.75.215.8) |
| 01:59.30 | DonkeyHotei | ehci = usb2 |
| 01:59.36 | gnarface | systemdlete: yea, that suggests either a driver problem or a physical link problem |
| 01:59.53 | gnarface | systemdlete: i mean, one or two are ok, but if it's spamming them repeatedly it's a problem |
| 02:00.03 | systemdlete | *was* spamming, yes |
| 02:00.04 | gnarface | systemdlete: though i think it could also be an issue with just a particular device doing that |
| 02:00.22 | gnarface | systemdlete: so it might not be the USB controller driver going awry, but just the driver for that one device (had problems like that with some webcams) |
| 02:00.26 | systemdlete | I could try plugging one of the two back in to a usb3 port at a time |
| 02:01.38 | mason | Hrm, without PulseAudio, Firefox can't talk to BlueJeans. Wacky. |
| 02:02.03 | mason | Other than that things seem to be working. |
| 02:02.28 | mason | I might want to switch from the nVidia DKMS from backports to the upstream package, but we'll see. |
| 02:03.06 | mason | But if I don't encounter any showstoppers, this'll be my workstation running Devuan. \o/ |
| 02:04.22 | DonkeyHotei | if by upstream you mean debian, ok. if by upstream you mean nvidia's own package, don't do that |
| 02:04.45 | mason | nVidia's own. Should be relatively safe, but if you've had bad experiences, I'm listening. |
| 02:05.43 | DonkeyHotei | my experiences may be out of date, but they were badly packaged, overwriting GL libraries irretrievably |
| 02:05.44 | mason | There, BlueJeans works with ALSA in Google Chrome and Chromium both. |
| 02:06.18 | mason | Oh, that'd kind of suck. My inspiration here is that the DKMS build failed to do something unspecified with nvidia-persistenced. |
| 02:06.34 | mason | It *works* but something was unhappy. |
| 02:07.15 | mason | Then again, I guess if it breaks I'll just fix it. |
| 02:07.36 | mason | But, alright, I'll stay away from the upstream. |
| 02:08.08 | DonkeyHotei | maybe you could try rebuilding the ubuntu package from the source package? idk |
| 02:08.37 | DonkeyHotei | only other real option |
| 02:09.02 | mason | Anyway, everything else is working. Email, GSSAPI, VPN, A/V stuff. Haven't encountered anything bad yet. I didn't expect to, but I'm still happy. Also, root on ZFS working nicely. |
| 02:09.46 | mason | I'll look at the Debian DKMS and see what it is about nvidia-persistenced. Maybe it insists on systemd or something. |
| 02:11.59 | mason | Oh, I guess it's effectively cosmetic and I was silly for not using --no-install-recommends per http://dev1galaxy.org/viewtopic.php?id=3372&p=4 |
| 02:12.17 | mason | Fixed. |
| 02:14.44 | gnarface | mason: nvidia's shell-script installer runs roughshod over the debian package tree heirarchy, causing permanent unrecoverable corruptions that linger silently until they destabilize your system or derail a future upgrade |
| 02:14.56 | mason | \o/ |
| 02:15.20 | gnarface | mason: it's really good at being the latest driver version, but if you need a newer version you should always try the package in backports first |
| 02:15.30 | mason | I've heard from a number of people who are very happy with it under Fedora, but it's probably assuming Fedora for its layout. |
| 02:15.59 | gnarface | mason: basically if you never go back and you were going to do a full reinstall at the next release anyway, then it's usually fine |
| 02:16.26 | gnarface | mason: if you want to successfully upgrade your same install across 6 releases though, stay far away from it |
| 02:16.47 | mason | Noted, and I'm happy to benefit from the collective suffering of those who have gone before me. :) |
| 02:17.45 | gnarface | mason: as for the bluejeans/pulseaudio thing, i'm guessing bluejeans must have something to do with bluetooth? bluez-alsa was removed from debian so now you need pulseaudio for bluetooth-alsa support, or you find someone's archive of bluez-alsa on github and just build it yourself |
| 02:18.10 | gnarface | *bluetooth-audio support, i mean |
| 02:18.17 | *** join/#devuan ham5urg_ (~ham5urg@2a04:4540:6804:b200:84b1:e6ae:5442:eae3) |
| 02:18.29 | mason | gnarface: BlueJeans is a commercial videoconferencing platform. Work uses it, and with PulseAudio it works on Firefox, but I'd rather use Chromium than have to install PulseAudio. |
| 02:18.35 | gnarface | mason: (in the latter case i think you also need to find a quick&dirty pairing app somewhere) |
| 02:18.46 | mason | I try to avoid BlueTooth like the plague. |
| 02:18.53 | mason | And wireless things generally. |
| 02:18.56 | gnarface | mason: oh, if it's not bluetooth related i dunno |
| 02:19.09 | gnarface | mason: you could try apulse but i haven't had luck recording with apulse |
| 02:19.20 | mason | I'm fine with Chromium honestly. |
| 02:19.41 | Artemis3 | mason, wireless is evil. Imagine, having to keep track even more battery based devices, its a nightmare i hate those things |
| 02:19.53 | mason | Yar. |
| 02:20.18 | debdog | I've been using ATI/AMD's and Nvidia's installers for many years with barely a problem. the trick is to uninstall it before a major distro update. |
| 02:21.22 | gnarface | debdog: that nvidia's installer has a working uninstall feature may be newer than my last experience with it |
| 02:22.09 | gnarface | hasn't used it since before devuan |
| 02:22.14 | mason | Mm, Steam works fine with ALSA. I'd have lived without it, but I'm happy not to have to. |
| 02:22.48 | gnarface | mason: oh, i actually found a few tricks to work around the one thing steam requires pulseaudio for |
| 02:23.06 | mason | What's that? |
| 02:23.19 | gnarface | mason: you'll only notice it missing for VOIP in certain games, or if you're doing in-home streaming |
| 02:23.25 | *** join/#devuan arnoldoree (~arnoldore@113.210.180.247) |
| 02:23.43 | mason | Oh, I never use voice in games. But what's your fix? |
| 02:24.26 | gnarface | mason: the VOIP in games can be fixed with a custom ~/.asoundrc, and audio in in-home streaming can be detoured to another device with alsa Loopback device trickery and netcat :) |
| 02:24.28 | *** join/#devuan D-HUND (~debdog@2a00:79c0:636:a400:7a24:afff:fe8a:d04d) |
| 02:25.17 | gnarface | mason: (probably could be just routed the same way to the steam link itself but only if you mod the linux install on the steamlink) |
| 02:25.29 | gnarface | mason: (i'm just using a nearby raspberry pi connected to the same stereo) |
| 02:25.54 | gnarface | mason: (you'd think delay is an issue but not if you run netcat in udp mode) |
| 02:26.56 | mason | hrm |
| 02:27.30 | gnarface | mason: oh, and there's a couple games that outright crash at launch without pulseaudio, but for those you can just make them fail over to alsa properly by... get this... symlinking libpulse-simple0 (or whatever it's called) to /dev/null from their install directories |
| 02:27.33 | mason | The only multiplayer I do is with people at most a room away, and I never stream, so I randomly avoid all those things. :) |
| 02:27.41 | gnarface | mason: anyway, you're not expected to retain all this info but if you run into trouble ask me again |
| 02:27.51 | mason | That's what logs are for. :) |
| 02:28.06 | mason | I don't have to retain everything, I just have to remember how to use grep. :P |
| 02:28.08 | gnarface | mason: i also have some udev rule fixes for using the steam controller without systemd |
| 02:28.19 | mason | Ah, I don't have one. I'm a dinosaur. |
| 02:28.26 | mason | Dying Light seems to work nicely. |
| 02:28.57 | gnarface | all i heard at launch was how it didn't, but lately all i hear is how fun it is, so they must have fixed the issues |
| 02:29.41 | mason | I don't remember when I started playing, but we love it here. I play it multiplayer with my wife and kids. |
| 02:30.03 | gnarface | sounds awesome |
| 02:30.05 | mason | Recommended. It's beautifully solid. Only issue is that you have to do a dance for multiplayer. |
| 02:31.02 | gnarface | dying light is a fps zombie hunter right? |
| 02:31.15 | mason | With parkour, yes. |
| 02:31.46 | gnarface | i highly recommend a controller with motion-capture aim for such games, of which the steam controller is one example, but i think steam actually supports the nintendo switch ones too now, lol |
| 02:31.59 | gnarface | so, you know, whatever works |
| 02:32.19 | mason | Honestly I just use my trackball. Have for years. |
| 02:32.25 | mason | <- dinosaur |
| 02:32.32 | gnarface | but i never thought i'd find a better controller for FPS games than a keyboard & high-res mouse combo, honestly |
| 02:32.39 | gnarface | i was sure of it |
| 02:32.41 | gnarface | so sure |
| 02:32.57 | gnarface | but my scores tell me i was wrong |
| 02:33.02 | mason | Maybe I'll try one someday. I'm not opposed. I suspect I Just don't game enough to have wanted more. |
| 02:33.06 | mason | hah |
| 02:33.25 | gnarface | dude my scores told OTHER PEOPLE i was wrong, and they notified me of it, before it stopped feeling awkward even |
| 02:34.16 | gnarface | but if you think about it, it makes sense. it changes point+click to something more directly representing actually pointing at the thing you're clicking on |
| 02:34.24 | gnarface | your brain literally has to do less work |
| 02:34.34 | gnarface | so it goes faster whether it feels like it or not |
| 02:34.49 | mason | Alright. I'll see about getting a controller. |
| 02:35.02 | gnarface | if you go for a steam controller, wait for the sale |
| 02:35.28 | mason | I saw one and passed. I think I might be happier with a traditional one. |
| 02:35.29 | gnarface | gamestop usually has used controllers for cheap though if you're not afraid of germs |
| 02:35.35 | mason | heh |
| 02:35.38 | mason | nowadays... |
| 02:36.18 | gnarface | oh |
| 02:36.32 | gnarface | if you get something from amazon though you can return it for no reason |
| 02:36.45 | gnarface | so you could just try it out and you're only down shipping if you don't like it |
| 02:36.53 | mason | We don't use Amazon. Nor Wal-Mart. We try to avoid corps wherever possible. |
| 02:37.01 | gnarface | oh, well that limits things |
| 02:37.35 | mason | Not as much as you might think! Took a while to adjust, but we're long since there. |
| 02:37.54 | gnarface | amazon's new policy reduces a lot of the risk, but i don't deny they're evil and your reasoning is probably sound |
| 02:38.21 | mason | Yar, it's mostly their treatment of their workers, but this might be better in #devuan-offtopic. |
| 02:38.31 | gnarface | yes, agreed, sorry |
| 02:38.37 | mason | Which, you should be in there! Come along! |
| 02:42.40 | Artemis3 | i wish amazon had a policy about inactive accounts |
| 02:43.14 | Artemis3 | i can pray someday they'll just lose the database and the backups |
| 02:48.26 | golinux | Not really worth dropping in here anymore. So sad . . . |
| 02:49.46 | gnarface | golinux: sorry. it only veered off-topic about 20 minutes back |
| 02:52.05 | *** join/#devuan Centurion_Dan (~Thunderbi@devuan/developer/centuriondan) |
| 03:17.28 | systemdlete | More joy: "nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead." This seems to be at least 3-4 years old judging by hits by DDG. Harmless or a serious problem? |
| 03:17.53 | systemdlete | I'm running ufw/gufw here. |
| 03:18.26 | systemdlete | again, ascii 4.9.0-13 kernel; same physical host system. |
| 03:18.52 | *** join/#devuan nyov (~nyov@unaffiliated/nyov) |
| 03:18.58 | mason | systemdlete: I wouldn't have thought ASCII would ship nftables, but I might be confused. |
| 03:19.01 | systemdlete | this is after the system being up for a couple of days now. First time I think I have seen it. |
| 03:19.32 | mason | Oh, it's older than I realized. |
| 03:19.34 | systemdlete | mason: Wasn't iptables implemented as a front-end for netfilter so legacy software would run |
| 03:19.41 | systemdlete | ? |
| 03:19.51 | mason | systemdlete: Yeah, but that's newer. Unless, again, I'm confused. |
| 03:20.42 | mason | Yeah, this is what I'm thinking of: https://wiki.debian.org/nftables |
| 03:21.30 | mason | Not default until Buster/Beowulf, but I'm not sure when it was available, so maybe ASCII has it in some form. I don't use ufw, so I can't speak to that - bare iptables here, using the converter you noted. |
| 03:21.56 | mason | Anyway, g'night. |
| 03:22.06 | systemdlete | night and thank you |
| 03:34.12 | systemdlete | gnarface: For bonnie++, how do I specify the target filesystem or disk drive? This is not clear from the man pages. |
| 03:37.34 | *** join/#devuan pekman (~pekman@unaffiliated/pekman) |
| 03:38.41 | systemdlete | I'm guessing it is -d dir; this page indicates so: https://www.jamescoyle.net/how-to/599-benchmark-disk-io-with-dd-and-bonnie |
| 03:39.22 | systemdlete | but even there, he says: "-d â is used to specify the file system directory to use to benchmark." To me, that is not the same as saying "a directory on the filesystem to be benchmarked" |
| 03:39.48 | systemdlete | Ever the word nazi I am, but honestly, I wish devs would learn how to clearly document things. |
| 03:43.35 | *** join/#devuan Centurion_Dan (~Thunderbi@devuan/developer/centuriondan) |
| 04:02.49 | *** join/#devuan pekman (~pekman@unaffiliated/pekman) |
| 04:08.18 | *** join/#devuan ac_laptop (~ac_laptop@186.2.247.129) |
| 04:20.47 | *** join/#devuan pekman (~pekman@unaffiliated/pekman) |
| 04:24.31 | *** join/#devuan DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 04:28.40 | *** join/#devuan xrogaan (~xrogaan@unaffiliated/xrogaan) |
| 04:51.50 | *** part/#devuan linux_n (~guest@2605:e000:8b03:4800:4598:c614:dfaf:7f11) |
| 05:20.21 | *** join/#devuan Inepu (~Mithrandi@46.234.217.137) |
| 05:45.07 | *** join/#devuan skipshooter (markie@gateway/vpn/protonvpn/skipshooter) |