| jonadab | gnarface: Relatively? I guess I could test that by exiting it for a bit. | 00:05 |
|---|---|---|
| jonadab | Probably should, just to rule it out. | 00:05 |
| jonadab | I mean, irssi keeps logs, obviously. But that shouldn't cause anything like the level of usage I'm experiencing. | 00:05 |
| jonadab | FleaFart: Yes, it's a new install, as of, umm, Monday, IIRC. | 00:05 |
| gnarface | i admit it would seem that something must have gone terribly wrong, but also it is the only thing all your evidence points to | 00:06 |
| jonadab | But it's had apt-get update and apt-get dist-upgrade since install. | 00:06 |
| jonadab | gnarface: That doesn't explain why atop thinks init is responsible, though. | 00:06 |
| jonadab | That's a really odd piece of evidence that I don't know what to do with. | 00:07 |
| gnarface | jonadab: i thought you said it was the screen instance that contained irssi? | 00:07 |
| jonadab | irssi is running inside of screen, yes. | 00:07 |
| gnarface | if it is actually init, i would expect something is... initing alot | 00:07 |
| gnarface | got any programs stuck in a restart loop maybe? | 00:07 |
| jonadab | Hmm, there's a thought. | 00:08 |
| jonadab | Not that I _know_ of, but... | 00:08 |
| jonadab | Maybe I should do a reboot. | 00:08 |
| gnarface | you said you had no swap, too, right? so if you have no swap, and you're using all the ram you're gonna see weird out-of-memory behaviors (like stuff that logs needing to flush logs to disk more often) | 00:08 |
| jonadab | Hang on, I'm gonna quit irssi temporarily just to verify it's not the problem. Pretty sure it's not, but I'm gonna just _verify_ that. | 00:08 |
| jonadab | I have swap enabled, but if I turn it off, makes no difference. | 00:09 |
| jonadab | It's a swap partition. | 00:09 |
| jonadab | 16GB, all unused. | 00:09 |
| gnarface | if you run "iotop -a" then you should see something accumulating reads or writes, if this is actually disk traffic | 00:09 |
| jonadab | Hmm, iotop -a shows to main things doing disk activity: kworker/0:1 and jbd2/sda3-8 | 00:10 |
| * jonadab quits irssi temporarily. bfb | 00:11 | |
| jonadab | *brb | 00:11 |
| * jonadab is back; quitting irssi changed nothing at all, as expected. | 00:12 | |
| gnarface | hmmm | 00:13 |
| gnarface | jonadab: raid array by any chance? | 00:13 |
| jonadab | No. | 00:13 |
| jonadab | And I haven't set up over-the-network backups yet, because the install is so new I was still getting things installed. | 00:14 |
| jonadab | Hadn't even got Bitlbee fully operational yet. | 00:14 |
| gnarface | jonadab: in some configurations ext4 is set up to lazy-format the rest of the disk's empty space after install, which would cause behavior like this (a few days of ghost disk activity that is difficult to diagnose but goes away eventually) but mostly i thought that's something only people installing to RAID were seeing happening as a default setting | 00:14 |
| jonadab | Hmm. | 00:15 |
| jonadab | THat WOULD explain what I'm seeing. | 00:15 |
| jonadab | Especially as it would be happening presumably in kernel space, which would explain why top and friends can't pin it down. | 00:15 |
| jonadab | How long would this normally be expected to take for a 2TB SATA disk? | 00:15 |
| jonadab | (Approximately) | 00:16 |
| gnarface | like days or weeks | 00:16 |
| gnarface | you'd know, because at install time it didn't take several hours to finish formatting | 00:16 |
| jonadab | Ok, this has been since some time Monday, which is well within that range. | 00:16 |
| jonadab | Hmm. | 00:16 |
| jonadab | That sounds rather plausible. | 00:16 |
| jonadab | Actually. | 00:16 |
| jonadab | Install went... fairly quickly. | 00:16 |
| jonadab | If that's what it is, then I can just wait and it'll finish. | 00:17 |
| jonadab | Eventually. | 00:17 |
| jonadab | Is there a way to _check_ whether this is the case? | 00:17 |
| gnarface | if you ext4 formatted a 2TB disk and it finished in "seconds" (like less than several hundred seconds) it's impossible that it finished formatting for real. so this could be your issue. | 00:17 |
| jonadab | I don't remember how long the format took. | 00:17 |
| gnarface | iirc that would be minimum half an hour, but more likely more like ... i dunno 3 or 4 hours? | 00:17 |
| specing | jonadab: use btrfs | 00:17 |
| jonadab | Wasn't really timing it. (I was doing multiple things...) | 00:18 |
| gnarface | definitely not "seconds" like other filesystems (xfs, reiserfs, btrfs?) | 00:18 |
| jonadab | It wasn't 3-4 hours though. Definitely wasn't that long. | 00:18 |
| jonadab | I'd have noticed. | 00:18 |
| gnarface | jonadab: i forget how they were seeing that... i thought there was some process with extsomething in the name | 00:18 |
| jonadab | I don't suppose tune2fs or somesuch can tell me? | 00:18 |
| gnarface | something CAN tell you i just forget what, sorry | 00:19 |
| gnarface | a mount option, a stray process... maybe something in dmesg | 00:19 |
| jonadab | Hmm, ps -A | grep ext shows two processes called ext4-rsv-conver | 00:19 |
| jonadab | (That may be truncated) | 00:19 |
| gnarface | keyboard batteries, amirite? | 00:22 |
| gnarface | (sorry about the delayed response) | 00:22 |
| gnarface | jonadab: i don't have that process anywhere on my systems. most of them are NOT running ext4 but it also doesn't even look familiar, and it matches the pattern of the process name in my dim recollection as starting with the prefix "ext4-" | 00:23 |
| gnarface | jonadab: so i'd say that's your prime suspect right now | 00:23 |
| jonadab | Yeah, this is starting to feel like a really plausible explanation. | 00:24 |
| gnarface | a 2TB disk drive formatted fully with ext4 would have taken somewhere approximating the same time it takes to fat32 format a drive without the quick-format option | 00:24 |
| gnarface | so if it didn't take long enough for you to get annoyed at how long it was taking to format, if it didn't even take long enough for you to notice... then it didn't really format it | 00:25 |
| jonadab | Makes sense. | 00:25 |
| gnarface | several other filesystems available don't behave this way. i'm told it has something to do with them being journaling filesystems from the ground-up, while ext3 and ext4 are basically just ext2 with a journaling layer bolted onto the side | 00:26 |
| agris | gnarface, ext4 is a lot more than ext2 with journaling | 02:30 |
| agris | you have indexing, encryption, rework of the entire inode structure for extremely fast fscks | 02:30 |
| agris | to say ext4 is just ext2 with journaling bolted on would be inaccurate | 02:31 |
| agris | and yes, you can format a multiterabyte block device with ext4 in seconds. that's completely normal if you skip the badblocks stage | 02:32 |
| agris | mkfs.ext4 does not require you to zero the disk | 02:33 |
| gnarface | all false | 02:33 |
| gnarface | well maybe not the first part | 02:33 |
| gnarface | fsck is absolutely no faster | 02:34 |
| gnarface | and neither is formatting, even without doing the badblocks test (which expands "hours" to "days" for disks that size) | 02:34 |
| 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' | 02:35 |
| gnarface | well, i suspect you've been mislead on the formatting speed specifically | 02:35 |
| 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 | 02:36 |
| 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 | 02:36 |
| gnarface | (i really thought that was only RAID guys getting that by default but apparently i'm wrong) | 02:36 |
| gnarface | and as far as i can tell, everyone is making the fsck process "faster" by simply sabotaging it so it doesn't happen | 02:37 |
| gnarface | that seems to be the new popular distro thing these days is to omit fsck | 02:37 |
| agris | here i'll prove it. I've got an ext4 external2tb right here filled with movies | 02:37 |
| agris | setup with all the proper filesystem features enabled | 02:38 |
| gnarface | i assume so that when everyone's disks unravel they can push some new filesystem they're selling | 02:38 |
| gnarface | and what are the proper filesystem features, if not "default" ? | 02:38 |
| gnarface | or "defaults" or whatever it's called? | 02:38 |
| 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. | 02:39 |
| agris | http://dpaste.com/3WHAENQ | 02:40 |
| 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 | 02:40 |
| agris | That's an ext3 problem NOT an ext4 problem | 02:40 |
| jonadab | Ah? Ok, could be. I think most of my experience is with ext2/3. | 02:41 |
| jonadab | (Well, and previously with FAT12, FAT16, and FAT32.) | 02:41 |
| jonadab | (And the occasional odd bit of ntfs or iso9660 on the side, of course.) | 02:41 |
| agris | man 5 ext4 | 02:42 |
| agris | >This ext4 feature | 02:43 |
| agris | >his feature is supported by ext2, ext3, and ext4. | 02:43 |
| jonadab | The filesystem feature I _really_ want, and have wanted for years, is VMS-style file versioning. | 02:43 |
| agris | >This feature is supported by ext3 and ext4 file systems, and is ignored by | 02:43 |
| agris | ext2 file systems. | 02:43 |
| agris | check to see if uninit_bg is enabled | 02:44 |
| agris | > The kernel will keep a high watermark of unused inodes, and initialize inode | 02:45 |
| agris | tables and blocks lazily. This feature speeds up the time to check the file system using e2fsck(8), and it also speeds up the time required for | 02:45 |
| agris | mke2fs(8) to create the file system. | 02:45 |
| 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 | 02:46 |
| 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 | 02:49 |
| agris | http://dpaste.com/3RSYSWN | 02:49 |
| agris | that is also filled to the brim with 97% usage | 02:50 |
| agris | my bad 89% | 02:50 |
| agris | /dev/sdd1 1.8T 1.5T 206G 89% /mnt | 02:50 |
| agris | jonadab, Would OpenZFS snapshotting provide the versioning your looking for? not familiar with VMS a whole lot | 02:58 |
| agris | https://kernelnewbies.org/Ext4#EXT4_features | 03:01 |
| agris | gnarface, you are somewhat correct about ext3 being mostly just ext2 with journaling. however notso for ext4 | 03:03 |
| 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. | 03:03 |
| 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 | 03:09 |
| agris | and then setting up BIOS Alarm so that the computer automatically boots back up before the workday starts | 03:10 |
| agris | also disconnect the reset button if that's there too | 03:10 |
| agris | and again, if fsck is taking hours not minutes, make sure the proper ext4 features are turned on | 03:11 |
| 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) | 03:13 |
| gnarface | ... my statement that "if you didn't notice how long it took to format, it didn't do it" is not wrong | 03:14 |
| agris | gnarface, incorrect. 208GB free of 2TB. and that disk is worst case archive disk at lowest RPM over lowest speed interface. | 03:15 |
| jonadab | agris: Not really, no. | 03:15 |
| gnarface | agris: he would definitely have noticed 7 minutes * whatever the differential is in disk size here | 03:16 |
| 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. | 03:16 |
| jonadab | You can read a particular version of a file at any time by appending ; and the version number to the filename. | 03:17 |
| jonadab | Obviously, you do that for certain types of files (lock files, PID files, etc.) | 03: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 | 03:18 |
| jonadab | Err, do that when _writing_ them, so there's only one version, for those types of files. | 03:18 |
| gnarface | agris: i contest that as well. XFS only looks heavier because it can use more than one core. | 03:19 |
| jonadab | But if you don't specify, you get versioning. Automatically. Which is awesome. | 03:19 |
| agris | there's a lot more than core utilization that goes into filesystem performance | 03:20 |
| 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 | 03:20 |
| agris | > it's not quite as good at retaining that last-minute write data during hard power failures | 03:20 |
| jonadab | Power failures should be illegal ;-) | 03:21 |
| 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 | 03:21 |
| jonadab | (Also | 03:21 |
| gnarface | my desktops all have a UPS | 03:21 |
| golinux | Mine too | 03:21 |
| 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.) | 03:22 |
| gnarface | the power grid in LA is as dirty as everything else here. you need a UPS | 03: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 | 03:22 |
| golinux | Gives me time to exit gracefully if I'm working | 03:22 |
| agris | desktops have low-latency and low ram | 03:22 |
| 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 | 03:23 |
| agris | but again test it, because XFS doesn't optimize as hard for sequential block allocation as ext4 does | 03:24 |
| jonadab | My desktop's workload is probably more similar to a server, than to the average person's desktop. | 03:24 |
| gnarface | TwistedFate said Steam starts way faster on XFS | 03:24 |
| gnarface | i imagine what you'd see is notably faster load times, but probably also notably higher CPU load during updates/patches | 03:25 |
| agris | meaning large file reads on spinning disks will suffer | 03:25 |
| gnarface | no, the benchmarks in the wild suggest only the writes suffer. it reads faster than ext4 | 03:25 |
| TwistedFate | steam or other program startup time is criminally slow on devuan | 03:25 |
| TwistedFate | even with XFS it starts slow, on funtoo it was almost instant | 03:26 |
| 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 | 03:26 |
| 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 | 03:26 |
| gnarface | agris: they have had all kinds of problems with non-ext* filesystems | 03:27 |
| gnarface | agris: usually to do with the patching | 03:27 |
| agris | but hell, steam games can even break on ext4 filesystems larger than 2tb, because ext4 can also use 64bit inodes | 03:28 |
| gnarface | i haven't seen this yet, but do you know of some specific games that were known offenders here? | 03:28 |
| agris | and for some stupid reason, steam is _STILL_ 32bit X86 binary | 03:28 |
| agris | Dying Light comes to mind | 03:28 |
| gnarface | hmmm, not one i have, but noted. | 03:29 |
| agris | they may have fixed it by now don't know. early this year they made huge improvements to the linux version. | 03:29 |
| gnarface | that one had a lot of launch options though i remember. i don't think it was high quality | 03:29 |
| gnarface | s/launch options/launch issues/ | 03:29 |
| agris | used to crash to desktop every 30 minutes | 03:29 |
| gnarface | yea and some rendering problems too | 03:29 |
| agris | now only crashes to desktop every 2.5 hours | 03:29 |
| gnarface | hehe | 03:29 |
| gnarface | well it only took them about 2 decades to get l4d stable | 03:30 |
| agris | oh your not running Ubuntu 14.01? fuck you then I won't even accept your coredumps | 03:30 |
| agris | *disconnects support session* | 03:30 |
| gnarface | ah, good times | 03:30 |
| agris | who still even runs Ubuntu 14.01 in 2019? That's a big if even for an ubuntu userbase | 03:32 |
| 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 | 03:34 |
| gnarface | usually it's faster to start the second time in the same day | 03:34 |
| agris | that's probably accurate, as my steam library is split across a multi-device ZFS mirror and a dedicated ext4 SSD | 03:36 |
| 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 | 03:37 |
| agris | I don't think steam's bottleneck is diskio related | 03:37 |
| gnarface | eh, sometimes it is, sometimes it isn't. it is doing enough stuff really weirdly that you can't just assume | 03:38 |
| agris | steam also runs a big atrociously written bash script where it tries to abuse sudo before it starts up | 03:38 |
| gnarface | it's clear evidence of a whole lot of bad ideas inherited from the Windows ecology | 03:38 |
| gnarface | but | 03:38 |
| gnarface | now we're far off topic | 03:38 |
| gnarface | we should talk about this type of stuff in #debianfork | 03:39 |
| gnarface | (if anyone wants help getting Steam or Steam hardware working in devuan though, i have found some important tricks) | 03:39 |
| agris | so have i | 03:40 |
| 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 | 03:44 |
| agris | https://kernelnewbies.org/Ext4#Migrate_existing_Ext3_filesystems_to_Ext4 | 03:44 |
| gnarface | noted, thanks | 03:44 |
| 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 | 03:45 |
| gnarface | they weren't ready and everyone pushed it up to be the default too soon | 03:46 |
| gnarface | and i swear some of those installs were fresh ext4 formats, they weren't all ext3 upgrades | 03:49 |
| 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 | 03:49 |
| 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 | 03:50 |
| agris | yes, ext4 was originally pushed out too soon but by now it's very mature | 03:50 |
| 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 :) | 03:51 |
| 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 | 03:51 |
| gnarface | hmm, indeed. | 03:52 |
| gnarface | i don't actually trust XFS that much | 03:55 |
| gnarface | but i've had surprisingly few issues with it | 03:55 |
| gnarface | agris: what do you know about mitigating SSD wear with ext4? | 03:57 |
| gnarface | agris: do you recommend raising the value of the "commit" mount option? | 03:59 |
| agris | no just mount with the discard option and relatime | 04:00 |
| agris | use a namebrand SSD with decent firmware like Samsung or Corsair | 04:01 |
| agris | all my SSDs are sumsung | 04:01 |
| agris | except for an Intel flash which I don't use anymore and a Munchskin which I threw in the garbage where it belongs | 04:03 |
| 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? | 04:07 |
| gnarface | hmm, discard? | 04:07 |
| gnarface | agris: that's for reducing wear, not increasing performance? | 04:08 |
| agris | that's for both | 04:09 |
| gnarface | but that's only for some SSDs? | 04:09 |
| agris | for SSD devices and sparse/thinly-provisioned LUNs | 04:09 |
| gnarface | but any SSD devices? | 04:15 |
| gnarface | is it smart enough to enable it by default? | 04:16 |
| agris | not consistently | 04:17 |
| agris | you'll want to enable discard yourself | 04:17 |
| TwistedFate | welp, my plasma is dying | 04:48 |
| TwistedFate | [ 6887.281224] plasmashell[9045]: segfault at 8 ip 00007efbfd2a2bb7 sp 00007ffbffff5640 error 4 in libQt5Core.so.5.12.5[7efbfd076000+2d1000] | 04:48 |
| agris | prey to Lord Linus for the holy patches | 04:52 |
| 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? | 07:00 |
| agris | cheat engine is only for Windows | 07:01 |
| 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. | 07:01 |
| 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 | 07:02 |
| furrywolf | if you want lower-level, you can poke around /proc/<pid> | 07:02 |
| agris | I want some sharper tools than procfs | 07:03 |
| agris | furrywolf, https://invidio.us/watch?v=PUqSPiJ4BwQ | 07:04 |
| agris | wait | 07:11 |
| agris | Are you suggesting I just use a standard file hex editor to the memory of the userspace program via procfs? | 07:12 |
| agris | that's hardly ideal. I'd have to refresh the hex editor to get a live monitor. that's not realtime | 07:13 |
| furrywolf | dunno. as I said, I had no idea what cheat engine was. :P | 07:13 |
| agris | sent you a video of CE's memory monitor in use | 07:13 |
| agris | https://invidio.us/watch?v=PUqSPiJ4BwQ | 07:14 |
| furrywolf | yes, after I made the suggestion. and it's bedtime, not 22 minute video time. | 07:14 |
| agris | https://upload.nuegia.net/6aaf1d60-6a3b-479b-ac72-6cc67f79148e/screenshot.png | 07:16 |
| furrywolf | given the relatively small usefulness of such a utility (gdb does most useful things), I don't know if one exists or not. | 07:19 |
| agris | pitty | 07:21 |
| agris | anybody else know of a realtime memory monitor? | 07:21 |
| FatPhil_ | gdb is the standard way of probing around within a process' address space. /proc/$PID/maps can help you know where to look | 10:34 |
| 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 | 20:21 |
| mason | tse: Are you able to sleep manually with pm-suspend? | 20:26 |
| 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. | 20:27 |
| tse | after having added a line to /etc/sudoers to allow my user to sudo pm-suspend, yes I can. | 20:28 |
| tse | but the problem is that the branch that should run pm-suspend is not even ran, due to that if failing :( | 20:28 |
| mason | tse: Half a sec, installing that stuff and I'll have a look. I vaguely remember needing some hand-tweaking under Wheezy. | 20:29 |
| tse | thank you. | 20:29 |
| mason | tse: Random note while I poke around, in addition to the acpi-support you installed, there's also laptop-mode-tools. | 20:31 |
| mason | But I'll look at the one you've got. | 20:31 |
| tse | oh I was not aware of that package. Which one should I install? Or should I install both? | 20:32 |
| mason | tse: Did you edit /etc/default/acpi-support? | 20:32 |
| mason | tse: Let's stick with the one you've got. | 20:32 |
| mason | tse: Here's my guess... | 20:33 |
| tse | no, I did not touch that file | 20:33 |
| mason | tse: I bet you didn't edit /etc/default/acpi-support, so go in there and uncomment lid support, then service acpid restart | 20:33 |
| tse | 1 sce | 20:33 |
| tse | that did the trick mason ! thank you very much :) | 20:37 |
| tse | about that laptop-mode-tools package however, where can I read more about it vs acpi-support? | 20:37 |
| 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. | 20:38 |
| 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. | 20:39 |
| 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? | 20:40 |
| 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. | 20:42 |
| mason | tse: If you want it as THE init, it might be worth your exploring it and writing up docs. | 20:42 |
| tse | ok that's fair enough :) | 20:42 |
| mason | I'm part of the lazy crew that just wants plain sysvinit. | 20:42 |
| 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 :) | 20:43 |
| mason | tse: There is mention of moving to runit here on Debian: https://wiki.debian.org/Init | 20:44 |
| 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? | 20:45 |
| 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. | 20:46 |
| 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? | 20:47 |
| tse | (brb) | 20:49 |
| mason | I'm not as hopeful as I'd like to be. | 20:49 |
| MinceR | who knows, maybe they'll do it in a single release just to stuff systemd down the suckers' throats again in the next | 20:50 |
| mason | MinceR: If they make it impossible to easily maintain sysvinit, I'm going back to my Slackish fork. | 20:51 |
| mason | MinceR: But until then, Devuan's pretty much what I'd want as an end result, so it makes sense to spend more time here. | 20:52 |
| MinceR | i was talking about debian | 20:52 |
| MinceR | i trust devuan to stay off systemd for as long as resources allow | 20:52 |
| mason | MinceR: That's what I'm saying. Debian could make it too painful. | 20:52 |
| MinceR | :) | 20:52 |
| mason | I hope they don't, but that's where I don't hold out a lot of hope. | 20:53 |
| mason | MinceR: PM? | 20:54 |
| MinceR | sure | 20:54 |
| tse | Yeah, I'm currenlty in a distro hoping fiesta again. Slack has a lot of rough edges, gentoo is too brittle (in my hands) + a lot of compiling, not cool on a laptop. the remaining choices were devuan and void. Since I need to use this for work as well, I would rather only run one distro, and I'm a bit afraid of running void on the worklaptop (I'm afraid an upgrade will break my system - even if only | 20:55 |
| tse | temporarily) | 20:55 |
| tse | so even if some packages are a bit outdated, or outright not available, I believe devuan to be the better option | 20:55 |
| djph | well, devuan is simply "debian-sans-systemd" ... so it should be as up-to-date as whatever debian is doing | 21:01 |
| golinux | djph: There was more to that discussion | 21:02 |
| djph | there was? | 21:03 |
| djph | :( | 21:03 |
| mason | tse: Devuan is really pleasant. It's all the good of Debian, no systemd. | 21:03 |
| djph | I think I lost some scrollback somewhere | 21:03 |
| tse | mason: I'll be running it for a while now :) | 21:05 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
