| 00:00.22 | *** join/#devuan poontangmessiah (~poontangm@unaffiliated/poontangmessiah) |
| 00:02.33 | *** join/#devuan zeden (~user@unaffiliated/zeden) |
| 00:06.51 | *** join/#devuan poontangmessiah_ (~poontangm@unaffiliated/poontangmessiah) |
| 00:13.54 | *** join/#devuan bpmedley (~bpm@2601:246:8201:8e0:79b2:66c7:7846:1d63) |
| 00:28.45 | *** join/#devuan poontangmessiah (~poontangm@unaffiliated/poontangmessiah) |
| 00:29.15 | *** join/#devuan danyspin97 (~danyspin9@liveunix.org) |
| 00:30.00 | agris | gnarface, ext4 is a lot more than ext2 with journaling |
| 00:30.46 | agris | you have indexing, encryption, rework of the entire inode structure for extremely fast fscks |
| 00:31.25 | agris | to say ext4 is just ext2 with journaling bolted on would be inaccurate |
| 00:32.55 | agris | and yes, you can format a multiterabyte block device with ext4 in seconds. that's completely normal if you skip the badblocks stage |
| 00:33.17 | agris | mkfs.ext4 does not require you to zero the disk |
| 00:33.28 | gnarface | all false |
| 00:33.34 | gnarface | well maybe not the first part |
| 00:34.22 | gnarface | fsck is absolutely no faster |
| 00:34.53 | gnarface | and neither is formatting, even without doing the badblocks test (which expands "hours" to "days" for disks that size) |
| 00:35.16 | agris | gnarface, if that's how it's been in your experience you probably have some of the ext4 features disabled or set to 'runtime mode' |
| 00:35.37 | gnarface | well, i suspect you've been mislead on the formatting speed specifically |
| 00:36.08 | gnarface | lots of people seem to be getting that lazy/fast format by default and simply not noticing the ensuing ghost disk activity after install |
| 00:36.21 | agris | this can happen if you don't fully follow through with the ext3->ext4 conversion procedure or when you created the ext4 filesystem you explicit set certain features to disabled/runtime in order to maintain ext3/2 backwards compatibility |
| 00:36.25 | gnarface | (i really thought that was only RAID guys getting that by default but apparently i'm wrong) |
| 00:37.08 | gnarface | and as far as i can tell, everyone is making the fsck process "faster" by simply sabotaging it so it doesn't happen |
| 00:37.34 | gnarface | that seems to be the new popular distro thing these days is to omit fsck |
| 00:37.49 | agris | here i'll prove it. I've got an ext4 external2tb right here filled with movies |
| 00:38.02 | agris | setup with all the proper filesystem features enabled |
| 00:38.06 | gnarface | i assume so that when everyone's disks unravel they can push some new filesystem they're selling |
| 00:38.27 | gnarface | and what are the proper filesystem features, if not "default" ? |
| 00:38.38 | gnarface | or "defaults" or whatever it's called? |
| 00:39.20 | jonadab | The argument in favor of not doing fsck, is that people don't want to wait an hour for the computer to start when they turn it on. Not saying this is a _great idea_, but that's the motivation. |
| 00:40.07 | agris | http://dpaste.com/3WHAENQ |
| 00:40.36 | agris | ><jonadab> The argument in favor of not doing fsck, is that people don't want to wait an hour for the computer to start |
| 00:40.43 | agris | That's an ext3 problem NOT an ext4 problem |
| 00:41.02 | jonadab | Ah? Ok, could be. I think most of my experience is with ext2/3. |
| 00:41.31 | jonadab | (Well, and previously with FAT12, FAT16, and FAT32.) |
| 00:41.52 | jonadab | (And the occasional odd bit of ntfs or iso9660 on the side, of course.) |
| 00:42.40 | agris | man 5 ext4 |
| 00:43.05 | agris | >This ext4 feature |
| 00:43.15 | agris | >his feature is supported by ext2, ext3, and ext4. |
| 00:43.21 | jonadab | The filesystem feature I _really_ want, and have wanted for years, is VMS-style file versioning. |
| 00:43.28 | agris | >This feature is supported by ext3 and ext4 file systems, and is ignored by |
| 00:43.28 | agris | <PROTECTED> |
| 00:44.53 | agris | check to see if uninit_bg is enabled |
| 00:45.28 | agris | > The kernel will keep a high watermark of unused inodes, and initialize inode |
| 00:45.28 | agris | <PROTECTED> |
| 00:45.28 | agris | <PROTECTED> |
| 00:46.30 | *** join/#devuan zoobab (zoobab@vic.ffii.org) |
| 00:46.32 | agris | uninit_bg is NOT backwards compatible with ext2/3 and enabled it will prevent you from being able to mount an ext4 filesystem as ext3 |
| 00:49.44 | agris | and just for completeness sake, here's how long it takes under the worst case scenario. a 2TB ext4 filesystem @5400RPM over a USB converter |
| 00:49.45 | agris | http://dpaste.com/3RSYSWN |
| 00:50.06 | agris | that is also filled to the brim with 97% usage |
| 00:50.39 | agris | my bad 89% |
| 00:50.43 | agris | <PROTECTED> |
| 00:58.23 | agris | jonadab, Would OpenZFS snapshotting provide the versioning your looking for? not familiar with VMS a whole lot |
| 01:01.21 | agris | https://kernelnewbies.org/Ext4#EXT4_features |
| 01:03.35 | agris | gnarface, you are somewhat correct about ext3 being mostly just ext2 with journaling. however notso for ext4 |
| 01:03.38 | agris | >Ext4 is the evolution of the most used Linux filesystem, Ext3. In many ways, Ext4 is a deeper improvement over Ext3 than Ext3 was over Ext2. Ext3 was mostly about adding journaling to Ext2, but Ext4 modifies important data structures of the filesystem such as the ones destined to store the file data. The result is a filesystem with an improved design, better performance, reliability and features. |
| 01:05.34 | *** join/#devuan TwistedFate (~quassel@unaffiliated/twistedfate) |
| 01:06.50 | *** join/#devuan HumanG33k (~HumanG33k@62.147.242.8) |
| 01:09.13 | agris | if someone is REALLY that upset abot their computer taking a little longer to boot up due to ext4 checking, I'd recommend disconnecting the ACPI power button from their motherboard and training them on the proper way to shutdown a computer when finished with it |
| 01:09.54 | *** join/#devuan Human_G33k (~HumanG33k@62.147.242.8) |
| 01:10.03 | agris | and then setting up BIOS Alarm so that the computer automatically boots back up before the workday starts |
| 01:10.29 | agris | also disconnect the reset button if that's there too |
| 01:11.15 | agris | and again, if fsck is taking hours not minutes, make sure the proper ext4 features are turned on |
| 01:11.54 | *** join/#devuan TwistedFate (~quassel@unaffiliated/twistedfate) |
| 01:12.19 | *** part/#devuan james1138 (~james1138@71-222-133-42.albq.qwest.net) |
| 01:13.51 | gnarface | agris: well, the hours instead of minutes thing is noted. and maybe upgrading from ext3 might have something to do with that but you still posted a 7 minute format time on a 209GB disk, which would still be most of an hour for 2TB, so i maintain that compared to xfs for example, which will complete the same task in only a few seconds (literally) |
| 01:14.25 | gnarface | ... my statement that "if you didn't notice how long it took to format, it didn't do it" is not wrong |
| 01:15.10 | agris | gnarface, incorrect. 208GB free of 2TB. and that disk is worst case archive disk at lowest RPM over lowest speed interface. |
| 01:15.43 | jonadab | agris: Not really, no. |
| 01:16.48 | gnarface | agris: he would definitely have noticed 7 minutes * whatever the differential is in disk size here |
| 01:16.50 | jonadab | The way file versioning works in VMS is, you don't have to take any snapshots or do anything. When a file is changed, a new version is automatically created, unless you specifically specify a version number to overwrite. |
| 01:17.22 | jonadab | You can read a particular version of a file at any time by appending ; and the version number to the filename. |
| 01:18.08 | jonadab | Obviously, you do that for certain types of files (lock files, PID files, etc.) |
| 01:18.18 | agris | XFS is a good filesystem and I use it a lot, but I would not recommend it being the default. It's a lot heavier than ext4 and not the best option for most desktop workloads. It could actually give worse performance and interactivity if it's a low-end barebones office machine running a web browser/spreadsheet/music. For servers XFS by default sure or something running a database or needing parallel io |
| 01:18.28 | jonadab | Err, do that when _writing_ them, so there's only one version, for those types of files. |
| 01:18.42 | *** join/#devuan xcm (~xcm@ipa210.225.tellas.gr) |
| 01:19.00 | gnarface | agris: i contest that as well. XFS only looks heavier because it can use more than one core. |
| 01:19.15 | jonadab | But if you don't specify, you get versioning. Automatically. Which is awesome. |
| 01:20.04 | agris | there's a lot more than core utilization that goes into filesystem performance |
| 01:20.14 | gnarface | agris: the only reason i'd recommend hesitation on using xfs is that it's not quite as good at retaining that last-minute write data during hard power failures, but with distros sabotaging ext4 fsck setups by default that is hardly a difference that matters in the wild these days |
| 01:20.33 | agris | > it's not quite as good at retaining that last-minute write data during hard power failures |
| 01:21.16 | jonadab | Power failures should be illegal ;-) |
| 01:21.17 | agris | This is also true. and another reason why desktops probably shouldn't run XFS as they don't have UPS units or disk controller batteries and run a wider assortment of software increases risk of crash |
| 01:21.32 | jonadab | (Also |
| 01:21.37 | gnarface | my desktops all have a UPS |
| 01:21.48 | golinux | Mine too |
| 01:22.05 | jonadab | (Also, desktop PSUs ought to ship with small UPS batteries built in so they can weather one-second power blinks, which are way more common than longer outages.) |
| 01:22.06 | gnarface | the power grid in LA is as dirty as everything else here. you need a UPS |
| 01:22.22 | agris | It also contends to the way XFS uses the system memory. which is fine if your on a server which has tons of higher-latency ram |
| 01:22.27 | golinux | Gives me time to exit gracefully if I'm working |
| 01:22.35 | agris | desktops have low-latency and low ram |
| 01:22.44 | *** join/#devuan voker57 (f00b47@kvirc/developer/Voker57) |
| 01:23.35 | agris | but if you've got a big beefy gaming computer and your workload has lots of file descriptors open at the same time then maybe XFS on that kind of desktop can be a good idea |
| 01:24.17 | agris | but again test it, because XFS doesn't optimize as hard for sequential block allocation as ext4 does |
| 01:24.18 | jonadab | My desktop's workload is probably more similar to a server, than to the average person's desktop. |
| 01:24.29 | gnarface | TwistedFate said Steam starts way faster on XFS |
| 01:25.17 | gnarface | i imagine what you'd see is notably faster load times, but probably also notably higher CPU load during updates/patches |
| 01:25.31 | agris | meaning large file reads on spinning disks will suffer |
| 01:25.56 | gnarface | no, the benchmarks in the wild suggest only the writes suffer. it reads faster than ext4 |
| 01:25.57 | TwistedFate | steam or other program startup time is criminally slow on devuan |
| 01:26.18 | TwistedFate | even with XFS it starts slow, on funtoo it was almost instant |
| 01:26.35 | gnarface | agris: acutally, curiously writes and deletes suffer, but deletes don't suffer as much as they used to with the new default mount options |
| 01:26.54 | agris | gnarface, be carful with steam and XFS. (And this is not XFS's fault at all but the shitty blob-only software on steam) If an XFS filesystem is using 64-bit inodes a lot of steam games will break |
| 01:27.27 | gnarface | agris: they have had all kinds of problems with non-ext* filesystems |
| 01:27.39 | gnarface | agris: usually to do with the patching |
| 01:28.03 | agris | but hell, steam games can even break on ext4 filesystems larger than 2tb, because ext4 can also use 64bit inodes |
| 01:28.24 | gnarface | i haven't seen this yet, but do you know of some specific games that were known offenders here? |
| 01:28.29 | agris | and for some stupid reason, steam is _STILL_ 32bit X86 binary |
| 01:28.52 | agris | Dying Light comes to mind |
| 01:29.03 | gnarface | hmmm, not one i have, but noted. |
| 01:29.18 | agris | they may have fixed it by now don't know. early this year they made huge improvements to the linux version. |
| 01:29.18 | gnarface | that one had a lot of launch options though i remember. i don't think it was high quality |
| 01:29.29 | gnarface | s/launch options/launch issues/ |
| 01:29.38 | agris | used to crash to desktop every 30 minutes |
| 01:29.46 | gnarface | yea and some rendering problems too |
| 01:29.48 | agris | now only crashes to desktop every 2.5 hours |
| 01:29.53 | gnarface | hehe |
| 01:30.03 | gnarface | well it only took them about 2 decades to get l4d stable |
| 01:30.22 | agris | oh your not running Ubuntu 14.01? fuck you then I won't even accept your coredumps |
| 01:30.35 | agris | *disconnects support session* |
| 01:30.43 | gnarface | ah, good times |
| 01:32.23 | agris | who still even runs Ubuntu 14.01 in 2019? That's a big if even for an ubuntu userbase |
| 01:34.13 | gnarface | TwistedFate: it might have only been "instant" on funtoo because you had fewer games installed, some of the start-up delay is a factor of how many games it has to check with the server about updates/DRM for |
| 01:34.59 | gnarface | usually it's faster to start the second time in the same day |
| 01:36.56 | agris | that's probably accurate, as my steam library is split across a multi-device ZFS mirror and a dedicated ext4 SSD |
| 01:37.44 | gnarface | there seems to be a 3rd cycle too, where the client itself checks for updates at launch, which doesn't seem to happen every time, and that can seem to trigger an extra long game index update for some reason |
| 01:37.51 | agris | I don't think steam's bottleneck is diskio related |
| 01:38.16 | gnarface | eh, sometimes it is, sometimes it isn't. it is doing enough stuff really weirdly that you can't just assume |
| 01:38.41 | agris | steam also runs a big atrociously written bash script where it tries to abuse sudo before it starts up |
| 01:38.42 | gnarface | it's clear evidence of a whole lot of bad ideas inherited from the Windows ecology |
| 01:38.55 | gnarface | but |
| 01:38.58 | gnarface | now we're far off topic |
| 01:39.09 | gnarface | we should talk about this type of stuff in #debianfork |
| 01:39.47 | gnarface | (if anyone wants help getting Steam or Steam hardware working in devuan though, i have found some important tricks) |
| 01:40.01 | agris | so have i |
| 01:44.28 | agris | gnarface, if you are still having performance issues with your filesystem you have to do more than just mount it as ext4 to fully convert it. This guide has the details to finish the conversion |
| 01:44.29 | agris | https://kernelnewbies.org/Ext4#Migrate_existing_Ext3_filesystems_to_Ext4 |
| 01:44.48 | gnarface | noted, thanks |
| 01:45.58 | gnarface | i will revisit it at some point. i got so fed up with the disk corruption issue introduced by the e2fsprogs version mismatch in raspbian that i crossed ext4 off my personal list of trusted filesystems |
| 01:46.47 | gnarface | they weren't ready and everyone pushed it up to be the default too soon |
| 01:49.12 | gnarface | and i swear some of those installs were fresh ext4 formats, they weren't all ext3 upgrades |
| 01:49.39 | gnarface | but it's long enough ago now, maybe there were performance issues that have since been ironed out and i'm not giving it enough credit for making progress |
| 01:50.23 | agris | huh, using tune2fs -l on that filesystem I showed tests on shows not all the modern features were turned on yet so actually there are further improvements that could be made to improve it's performance |
| 01:50.43 | agris | yes, ext4 was originally pushed out too soon but by now it's very mature |
| 01:51.30 | gnarface | i'm going to give you the benefit of the doubt but i'm paranoid so i'm still suspicious someone might have paid you to say that :) |
| 01:51.41 | agris | I trust ext4 (not setup with batshit settings like it is on the pi) in terms of stability and maturity like I trust ZFS |
| 01:52.39 | gnarface | hmm, indeed. |
| 01:55.19 | gnarface | i don't actually trust XFS that much |
| 01:55.30 | gnarface | but i've had surprisingly few issues with it |
| 01:57.29 | gnarface | agris: what do you know about mitigating SSD wear with ext4? |
| 01:59.41 | gnarface | agris: do you recommend raising the value of the "commit" mount option? |
| 02:00.09 | agris | no just mount with the discard option and relatime |
| 02:01.03 | agris | use a namebrand SSD with decent firmware like Samsung or Corsair |
| 02:01.49 | agris | all my SSDs are sumsung |
| 02:03.05 | agris | except for an Intel flash which I don't use anymore and a Munchskin which I threw in the garbage where it belongs |
| 02:06.40 | *** join/#devuan n0a110w (~n0a110w@unaffiliated/n0a110w) |
| 02:07.33 | n0a110w | is there an ISO with only one El Torito boot record for BIOS? similar to the special iso that debian puts out for old Macs? |
| 02:07.37 | gnarface | hmm, discard? |
| 02:08.16 | gnarface | agris: that's for reducing wear, not increasing performance? |
| 02:09.14 | agris | that's for both |
| 02:09.36 | gnarface | but that's only for some SSDs? |
| 02:09.59 | agris | for SSD devices and sparse/thinly-provisioned LUNs |
| 02:15.50 | gnarface | but any SSD devices? |
| 02:16.13 | gnarface | is it smart enough to enable it by default? |
| 02:17.11 | agris | not consistently |
| 02:17.21 | agris | you'll want to enable discard yourself |
| 03:11.11 | *** join/#devuan infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 03:11.11 | *** topic/#devuan is This is the Devuan https://devuan.org/ discussion channel | D1conf: #devuan-conf https://devuan.org/d1conf | Latest (2018-06-09): ASCII 2.0.0 https://devuan.org/os/debian-fork/ascii-stable-announce-060818 || Stable (2017-05-25): Jessie 1.0.0 LTS release | Devuan Forum: https://dev1galaxy.org/ | Chanlogs http://maemo.cloud-7.de/irclogs/freenode/_devuan/ | You may need to auth to NickServ |
| 03:11.12 | *** mode/#devuan [+v infobot] by ChanServ |
| 03:46.49 | *** join/#devuan archetyp` (~archetyp@55d4f839.access.ecotel.net) |
| 04:12.06 | *** join/#devuan DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 04:17.26 | *** join/#devuan xrogaan (~xrogaan@unaffiliated/xrogaan) |
| 04:40.47 | *** join/#devuan wyatt8750 (~wyatt8740@149.164.111.64) |
| 04:41.45 | *** join/#devuan LtWorf_ (~LtWorf@h-191-254.A890.priv.bahnhof.se) |
| 05:00.39 | *** join/#devuan LtWorf (~LtWorf@mail.cryptzone.com) |
| 05:00.55 | agris | Is there a program I can use on Linux to examine and modify a program's memory live (while the program is running) and perform similar functions to cheat engine? |
| 05:01.04 | agris | cheat engine is only for Windows |
| 05:01.40 | furrywolf | I have absolutely no idea what cheat engine is, but gdb is the standard way you interact with the memory of a running program. |
| 05:02.25 | agris | the GNU debugger is pretty useful and I've used that in the past to extract fonts, pictures, and other data from dying programs (little endian cpus are weird) but as far as I know you must send a SIGSTOP to the process when debugging in with GDB |
| 05:02.26 | furrywolf | if you want lower-level, you can poke around /proc/<pid> |
| 05:03.58 | agris | I want some sharper tools than procfs |
| 05:04.03 | agris | furrywolf, https://invidio.us/watch?v=PUqSPiJ4BwQ |
| 05:11.58 | agris | wait |
| 05:12.29 | agris | Are you suggesting I just use a standard file hex editor to the memory of the userspace program via procfs? |
| 05:13.09 | agris | that's hardly ideal. I'd have to refresh the hex editor to get a live monitor. that's not realtime |
| 05:13.35 | furrywolf | dunno. as I said, I had no idea what cheat engine was. :P |
| 05:13.59 | agris | sent you a video of CE's memory monitor in use |
| 05:14.10 | agris | https://invidio.us/watch?v=PUqSPiJ4BwQ |
| 05:14.48 | furrywolf | yes, after I made the suggestion. and it's bedtime, not 22 minute video time. |
| 05:16.24 | agris | https://upload.nuegia.net/6aaf1d60-6a3b-479b-ac72-6cc67f79148e/screenshot.png |
| 05:19.18 | furrywolf | given the relatively small usefulness of such a utility (gdb does most useful things), I don't know if one exists or not. |
| 05:21.14 | agris | pitty |
| 05:21.29 | agris | anybody else know of a realtime memory monitor? |
| 05:31.42 | *** join/#devuan bjb (~bjb@sourcerer.ca) |
| 05:34.22 | *** join/#devuan antenagora (~antenagor@147.162.137.245) |
| 05:42.01 | *** join/#devuan freemangordon (~ivo@46.249.74.23) |
| 06:04.41 | *** join/#devuan sb35 (~sb35@23.111.78.46) |
| 06:10.07 | *** join/#devuan furrywolf (~furrywolf@172.58.92.29) |
| 06:21.01 | *** join/#devuan LtWorf_ (~LtWorf@2001:9b1:4041:e000:a634:d9ff:fec6:343c) |
| 06:24.13 | *** join/#devuan user844842 (user@gateway/vpn/mullvad/user844842) |
| 07:02.38 | *** join/#devuan Pali (~pali@Maemo/community/contributor/Pali) |
| 07:08.20 | *** join/#devuan puria (~puria@37.161.215.142) |
| 07:16.13 | *** join/#devuan puria (~puria@37.161.215.142) |
| 07:17.41 | *** join/#devuan puria (~puria@37.161.215.142) |
| 07:46.40 | *** join/#devuan omnio (~omnio@82.78.232.198) |
| 08:01.33 | *** join/#devuan rehcla (~rehcla@089144210248.atnat0019.highway.a1.net) |
| 08:06.06 | *** join/#devuan zatumil (~Administr@cgn-213-196-211-114.nc.de) |
| 08:13.03 | *** join/#devuan cocoadaemon (~foo@2a01:e35:8a99:e90:1202:b5ff:fe91:e4ca) |
| 08:13.32 | *** join/#devuan rdav (~rdav@110.193.150.122.sta.dodo.net.au) |
| 08:17.37 | *** join/#devuan puria (~puria@37.161.215.142) |
| 08:34.14 | FatPhil_ | gdb is the standard way of probing around within a process' address space. /proc/$PID/maps can help you know where to look |
| 08:34.55 | *** join/#devuan tierce_ (~raoulzeca@77.109.116.160) |
| 08:49.33 | *** join/#devuan Diagon (DiagonalAr@gateway/vpn/protonvpn/diagonalarg) |
| 09:01.00 | *** join/#devuan Dantalion (~Dantalion@217-120-205-175.cable.dynamic.v4.ziggo.nl) |
| 09:14.46 | *** join/#devuan rdav__ (~rdav@110.193.150.122.sta.dodo.net.au) |
| 09:58.00 | *** join/#devuan tierce_ (~raoulzeca@212.224.225.180) |
| 10:05.52 | *** join/#devuan Diagon (DiagonalAr@gateway/vpn/protonvpn/diagonalarg) |
| 10:20.25 | *** join/#devuan fleeky (~fleeky@2a02:8109:b6bf:c34c:df6c:7776:5758:b9ab) |
| 10:32.09 | *** join/#devuan xcm (~xcm@ipa210.225.tellas.gr) |
| 10:33.36 | *** join/#devuan puria (~puria@151.74.63.227) |
| 10:41.22 | *** join/#devuan puria (~puria@151.74.63.227) |
| 10:49.18 | *** join/#devuan archetyp (~archetyp@55d4f839.access.ecotel.net) |
| 11:20.44 | *** join/#devuan flrn (~flrn@unaffiliated/flrn) |
| 11:25.22 | *** join/#devuan cd (~cd@unaffiliated/cd) |
| 11:26.53 | *** join/#devuan TheCreeper (~TheCreepe@unaffiliated/thecreeper) |
| 11:30.25 | *** join/#devuan zeden (~user@unaffiliated/zeden) |
| 11:35.11 | *** join/#devuan zeden (~user@unaffiliated/zeden) |
| 11:39.26 | *** join/#devuan amarsh04 (~amarsh04@118.211.39.107) |
| 11:47.05 | *** join/#devuan xcm (~xcm@ipa210.225.tellas.gr) |
| 11:50.22 | *** join/#devuan jarfr (~jarfr@gateway/tor-sasl/jarfr) |
| 12:57.23 | *** join/#devuan TheCreeper (~TheCreepe@unaffiliated/thecreeper) |
| 13:12.34 | *** join/#devuan telst4r (~Jukka@fsf/member/telst4r) |
| 13:24.22 | *** join/#devuan Unit193 (ukikie@freenode/staff/ubuntu.member.unit193) |
| 13:31.50 | *** join/#devuan Lydia_K (~Lydia_K@li328-145.members.linode.com) |
| 13:48.02 | *** join/#devuan g4570n (~g4570n@unaffiliated/g4570n) |
| 13:58.08 | *** join/#devuan jarfr (~jarfr@gateway/tor-sasl/jarfr) |
| 14:03.27 | *** join/#devuan wyatt8750 (~wyatt8740@194.36.110.202) |
| 14:09.32 | *** join/#devuan puria (~puria@151.74.63.227) |
| 14:34.50 | *** join/#devuan furrywolf (~furrywolf@172.58.92.194) |
| 14:36.52 | *** join/#devuan xcm (~xcm@ipa210.225.tellas.gr) |
| 14:55.21 | *** join/#devuan wyatt8750 (~wyatt8740@149.164.111.64) |
| 15:13.06 | *** join/#devuan puria (~puria@151.74.63.227) |
| 15:26.44 | *** join/#devuan filipdevuan_ (~Justyna@cpc77042-warw18-2-0-cust394.3-2.cable.virginm.net) |
| 15:28.08 | *** join/#devuan xcm (~xcm@ipa210.225.tellas.gr) |
| 15:30.16 | *** join/#devuan jathan (~jathan@109.237.54.45) |
| 15:35.09 | *** join/#devuan Pali (~pali@Maemo/community/contributor/Pali) |
| 15:46.12 | *** join/#devuan retak_ (~ite@dslb-088-069-139-063.088.069.pools.vodafone-ip.de) |
| 16:00.28 | *** join/#devuan puria (~puria@151.74.63.227) |
| 16:12.14 | *** join/#devuan xinomilo (xinomilo@gateway/vpn/privateinternetaccess/xinomilo) |
| 16:34.47 | *** join/#devuan ymasson (~ymasson@lfbn-bor-1-147-114.w90-50.abo.wanadoo.fr) |
| 16:37.51 | *** join/#devuan wyatt8750 (~wyatt8740@194.36.110.202) |
| 16:40.21 | *** join/#devuan kts (~kts@103.73.237.193) |
| 16:41.02 | *** join/#devuan drmbls (~drmbls@78-63-188-55.static.zebra.lt) |
| 16:55.39 | *** join/#devuan poontangmessiah (~poontangm@unaffiliated/poontangmessiah) |
| 17:03.29 | *** join/#devuan omnio (~omnio@82.78.232.198) |
| 17:20.09 | *** join/#devuan ymasson (~ymasson@lfbn-bor-1-147-114.w90-50.abo.wanadoo.fr) |
| 17:22.12 | *** join/#devuan jathan (~jathan@109.237.54.45) |
| 17:23.31 | *** join/#devuan Ryushin (~Ryushin@2001:470:4b:3d3:12ae:fe1b:6718:7a19) |
| 17:26.33 | *** join/#devuan ahi2 (~ahi2@unaffiliated/ahi2) |
| 18:05.42 | *** join/#devuan zeden (~user@unaffiliated/zeden) |
| 18:07.12 | *** join/#devuan jathan (~jathan@109.237.54.45) |
| 18:15.48 | *** join/#devuan jathan (~jathan@109.237.54.45) |
| 18:20.59 | *** join/#devuan xkr47 (xkr47@host33-174.cust.ktab.fi) |
| 18:21.52 | tse | hello, I'm currently having some issues with suspend on lid close. The problem seems to be here: if [ x$LID_SLEEP = xtrue ]; (/etc/acpi/lid.sh). grep-ing for LID_SLEEP in /etc/acpi and /usr/share/acpi-support/screenblank yields no results. I'm on ascii |
| 18:26.55 | mason | tse: Are you able to sleep manually with pm-suspend? |
| 18:27.36 | mason | tse: I haven't looked at automation based on the lid recently, but I can if it seems broken. I prefer controlling it manually, so I can keep my laptop running for brief spans with the lid closed. |
| 18:28.02 | tse | after having added a line to /etc/sudoers to allow my user to sudo pm-suspend, yes I can. |
| 18:28.46 | tse | but the problem is that the branch that should run pm-suspend is not even ran, due to that if failing :( |
| 18:28.59 | *** join/#devuan james1138 (~james1138@71-222-133-42.albq.qwest.net) |
| 18:29.27 | mason | tse: Half a sec, installing that stuff and I'll have a look. I vaguely remember needing some hand-tweaking under Wheezy. |
| 18:29.59 | tse | thank you. |
| 18:31.20 | mason | tse: Random note while I poke around, in addition to the acpi-support you installed, there's also laptop-mode-tools. |
| 18:31.29 | mason | But I'll look at the one you've got. |
| 18:32.26 | tse | oh I was not aware of that package. Which one should I install? Or should I install both? |
| 18:32.39 | mason | tse: Did you edit /etc/default/acpi-support? |
| 18:32.45 | mason | tse: Let's stick with the one you've got. |
| 18:32.57 | *** join/#devuan Inepu (~Mithrandi@217-133-64-122.static.clienti.tiscali.it) |
| 18:33.10 | mason | tse: Here's my guess... |
| 18:33.15 | tse | no, I did not touch that file |
| 18:33.34 | mason | tse: I bet you didn't edit /etc/default/acpi-support, so go in there and uncomment lid support, then service acpid restart |
| 18:33.47 | tse | 1 sce |
| 18:37.22 | tse | that did the trick mason ! thank you very much :) |
| 18:37.44 | tse | about that laptop-mode-tools package however, where can I read more about it vs acpi-support? |
| 18:38.44 | mason | tse: You can download it and read the files. You should be able to use either one. That said, consider what I do and just sleep manually. It's really convenient shutting the lid, going to another room, opening it again. |
| 18:39.20 | mason | tse: Just be careful if you install them both, if the packages even allow that. They both try to do some of the same things. |
| 18:40.52 | tse | Thank you mason. I'll take that into account. While we're at it, I tried searching for devuan resources on how to use runit, but I came up short. Did I miss something on the website? |
| 18:41.53 | *** join/#devuan cocoadaemon (~foo@x53.octopuce.fr) |
| 18:42.20 | mason | tse: I'm not sure there's tooling to use that as your init. You can run it as a service monitor under sysvinit. |
| 18:42.34 | mason | tse: If you want it as THE init, it might be worth your exploring it and writing up docs. |
| 18:42.45 | tse | ok that's fair enough :) |
| 18:42.54 | mason | I'm part of the lazy crew that just wants plain sysvinit. |
| 18:43.27 | tse | I'm trying my best to have a reliable system, not a broken one, so I figure I 'm not the right man to brave those waters :) |
| 18:44.02 | mason | tse: There is mention of moving to runit here on Debian: https://wiki.debian.org/Init |
| 18:45.37 | *** join/#devuan mith_ (~Mithrandi@37.160.81.217) |
| 18:45.42 | tse | Oh, and there is another thing I would like to understand about devuan: is the objective of the distribution to always follow debian modulo systemd, or is it possible that in the future packages are added (or updated) out of sync with debian? |
| 18:46.24 | mason | tse: The former as I understand it. I think the tacit goal is for Debian to allow sysvinit (and possibly other inits) as first class citizens again. I suspect it'll have to be the latter eventually. |
| 18:47.22 | tse | you suspect it will have to be the former since you don't believe debian will ever have alternative init systems as first class citizens? |
| 19:02.13 | *** join/#devuan infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 19:02.13 | *** topic/#devuan is This is the Devuan https://devuan.org/ discussion channel | D1conf: #devuan-conf https://devuan.org/d1conf | Latest (2018-06-09): ASCII 2.0.0 https://devuan.org/os/debian-fork/ascii-stable-announce-060818 || Stable (2017-05-25): Jessie 1.0.0 LTS release | Devuan Forum: https://dev1galaxy.org/ | Chanlogs http://maemo.cloud-7.de/irclogs/freenode/_devuan/ | You may need to auth to NickServ |
| 19:02.13 | *** mode/#devuan [+v infobot] by ChanServ |
| 19:02.13 | *** join/#devuan petzi (~petzi@p578b3438.dip0.t-ipconnect.de) |
| 19:02.32 | golinux | djph: There was more to that discussion |
| 19:03.26 | djph | there was? |
| 19:03.29 | djph | :( |
| 19:03.32 | mason | tse: Devuan is really pleasant. It's all the good of Debian, no systemd. |
| 19:03.47 | djph | I think I lost some scrollback somewhere |
| 19:05.42 | tse | mason: I'll be running it for a while now :) |
| 19:13.47 | *** part/#devuan bergix59 (~bergix59@188-22-41-239.adsl.highway.telekom.at) |
| 19:33.06 | *** join/#devuan ferdy- (~ferdy@funtoo/contrib/ferdy-) |
| 19:43.36 | *** join/#devuan kts (~kts@103.73.237.193) |
| 20:14.21 | *** join/#devuan poontangmessiah_ (~poontangm@unaffiliated/poontangmessiah) |
| 20:14.31 | *** join/#devuan Condor (~freenode@www.nixmagic.com) |
| 20:25.47 | *** join/#devuan TwoTall (~TwoTall@unaffiliated/twotall) |
| 21:09.10 | *** join/#devuan DocScrutinizer05 (~saturn@openmoko/engineers/joerg) |
| 21:15.45 | *** join/#devuan rdav__ (~rdav@110.193.150.122.sta.dodo.net.au) |
| 21:28.05 | *** join/#devuan FleaFart (~FleaFart@76-10-135-247.dsl.teksavvy.com) |
| 21:29.07 | *** join/#devuan xkr47 (xkr47@host33-174.cust.ktab.fi) |
| 21:29.46 | *** join/#devuan xkr47_ (xkr47@host33-174.cust.ktab.fi) |
| 21:35.07 | *** join/#devuan poontangmessiah (~poontangm@unaffiliated/poontangmessiah) |
| 21:37.29 | *** join/#devuan xcm (~xcm@ipa210.225.tellas.gr) |
| 21:58.34 | *** join/#devuan rdav (~rdav@110.193.150.122.sta.dodo.net.au) |
| 22:02.32 | *** part/#devuan ahi2 (~ahi2@unaffiliated/ahi2) |
| 22:03.53 | *** join/#devuan petzi (~petzi@p578b3438.dip0.t-ipconnect.de) |
| 22:29.33 | *** join/#devuan TheCreeper (~TheCreepe@unaffiliated/thecreeper) |
| 22:42.24 | *** join/#devuan targz (~Thunderbi@unaffiliated/targz) |
| 22:49.33 | *** join/#devuan Oksana_ (~Wikiwide@ppp121-44-210-229.bras1.syd2.internode.on.net) |
| 22:49.56 | *** join/#devuan Oksana_ (~Wikiwide@Maemo/community/ex-council/Wikiwide) |
| 22:50.49 | *** join/#devuan filipdevuan_ (~Justyna@cpc77042-warw18-2-0-cust394.3-2.cable.virginm.net) |
| 23:03.31 | *** join/#devuan LtWorf_ (~LtWorf@2001:9b1:4041:e000:a634:d9ff:fec6:343c) |
| 23:16.57 | *** join/#devuan puria (~puria@37.162.157.21) |
| 23:19.59 | *** join/#devuan retak (~ite@dslb-188-107-168-186.188.107.pools.vodafone-ip.de) |
| 23:36.23 | *** join/#devuan rdav (~rdav@245.184-26-211.sta.nsw.iprimus.net.au) |
| 23:39.35 | *** join/#devuan LtWorf_ (~LtWorf@2001:9b1:4041:e000:a634:d9ff:fec6:343c) |
| 23:43.34 | *** join/#devuan ffurrywol (~furrywolf@172.58.92.55) |
| 23:49.39 | *** join/#devuan TwistedFate (~quassel@unaffiliated/twistedfate) |
