| fatso | the change to lightdm for some reason screwed up my scaling config | 00:15 |
|---|---|---|
| gnarface | fatso: here's what i have for mesa on current stable http://paste.debian.net/1319210/ (if the paste is still there, i put that up before you disconnected) | 00:16 |
| fatso | or maybe it was because i tried to use an x11 session? because it was screwed up on x11 first | 00:16 |
| gnarface | what were using to scale? | 00:16 |
| gnarface | did you make that xorg.conf change? | 00:16 |
| fatso | it's still there, thank you | 00:16 |
| gnarface | you probably don't need both architectures unless you're using Wine | 00:17 |
| fatso | i didn't but i configured sddm to reflect KDE's configuration, so now my SDDM login screen is exactly like my lock screen | 00:17 |
| fatso | and I didn't make the xorg.conf change | 00:18 |
| gnarface | what are you scaling, the entire desktop or just fonts? | 00:19 |
| gnarface | if it's the whole view, this may be something you can do with xrandr either on command-line or in the xorg.conf too | 00:19 |
| gnarface | if it's just fonts, i guess that's toolkit specific | 00:21 |
| fatso | it's the whole view | 00:24 |
| gnarface | yea, that's a xrandr thing i think, which means you can also specify it in xorg.conf with your intel driver if you want, or you can add it to a startup script with the console binary | 00:25 |
| gnarface | i dunno if the kde config will conflict but you can likely do it instead of | 00:25 |
| fatso | I'd rather not mess with it again haha | 00:37 |
| nemo | https://news.ycombinator.com/item?id=40578414 where does devuan stand on this? | 02:32 |
| nemo | will /var/tmp get erased prior to reboots? | 02:33 |
| rrq | what program/script would erase /var/tmp ? | 03:39 |
| buZz | rm | 03:41 |
| rrq | you mean that one of the rc6.d/K* files would have `rm /var/tmp/*` ? | 03:42 |
| buZz | oh, like that | 03:42 |
| buZz | could be? | 03:42 |
| rrq | none of mine though... and it depends on init system and setup I guess | 03:42 |
| rrq | according to FHS 3.0, /var/tmp contains "Temporary files to be preserved between reboots." | 03:46 |
| rrq | (but who bothers about FHS nowadays?) | 03:47 |
| buZz | well, systemd | 03:47 |
| buZz | :P | 03:47 |
| buZz | on this debian machine here its completely stuffed with systemd files | 03:48 |
| buZz | well, 10MB of it | 03:48 |
| Xenguy | I didn't know about /var/tmp, I always created my own directory off the / , to persist across reboots since /tmp flushes everything on reboot | 03:51 |
| rwp | The only totally safe time to remove things from /tmp and /var/tmp is at initial single user boot time before going multiuser and starting up sshd and gettys and such. That's why we usually clear /tmp at boot time. It's the safe time to do it. | 03:54 |
| rwp | But /var/tmp is supposed to preserve files across reboots. So that one is more problematic. Can't clear it at boot time. | 03:54 |
| Xenguy | Maybe /var/tmp is a feature and not a bug? | 03:54 |
| rwp | And there will be endless discussion about how to clear a temporary directory during the normal multiuser run time of the system in the presence of hostile agents operating on the system. | 03:55 |
| rwp | I went looking for the tmpreaper README and found a copy of it here: https://fossies.org/linux/tmpreaper/debian/README.security | 03:58 |
| rwp | It's good reading for the background of the problem of it on a multiuser system with malicious agents actively operating on it. | 03:59 |
| Xenguy | Fair enough, but it seems like if one has hostile users on a system the main battle has been lost? | 04:04 |
| rrq | mmm at most universities there are at least 2 students with accounts that will want to "break in"... which possibly counts as "hostile" | 04:06 |
| Xenguy | Sure they exist, but the main mission is to detect and ban such users, no? | 04:07 |
| rrq | or maybe find them and employ them :) | 04:10 |
| Xenguy | Friends and enemies I suppose : -) | 04:11 |
| fatso | kde says my thunderbolt subsystem is not available. Should I see it even when nothing is connected to it: | 05:34 |
| fatso | ? | 05:34 |
| fatso | I'm on a thinkpad T480, know to have thunderbolt issues, but successfully managed to update its firmware | 05:35 |
| fatso | *known | 05:36 |
| gnarface | fatso: dunno, did some quick searches though and i found one suggestion to disable "Thunderbolt BIOS Assist Mode" in the BIOS so fwupd can see it | 06:25 |
| gnarface | https://www.reddit.com/r/thinkpad/comments/12tf6xv/psa_t480_thunderbolt_controller_v23_is_now_on/ | 06:25 |
| fatso | I did it and updated the firmware | 06:28 |
| fatso | tried changing that setting to "enabled" and it resulted in thunderbolt not even being recognized by "lspci" | 06:29 |
| gnarface | i don't have one, but they're popular so someone around here certainly knows... | 06:38 |
| onefang | Am I doing something wrong, or does /var/cache/apt NOT like living in a symlink? I keep getting an extra / added between the path and the package when it's trying to find it during install. | 09:26 |
| amarsh04 | hmm... package hd-idle is still broken in Devuan - I had reported a bug against it in Debian but it hasn't been fixed | 10:57 |
| cousin_luigi | amarsh04: Which one are you talking about? | 11:06 |
| cousin_luigi | amarsh04: 1.05 is seemingly abandoned, debian testing has switched to the 1.21 go reimplementation | 11:06 |
| amarsh04 | Debian bug 1069637, version 1.21 doesn't appear to work with Devuan | 11:08 |
| cousin_luigi | amarsh04: Is it about the configuration file in /etc/default ? | 12:56 |
| amarsh04 | if one installs the later version, it default to hanging as sane defaults (even disabling by default) are not provided | 13:00 |
| cousin_luigi | amarsh04: I'm sorry, are you running Daedalus? | 13:08 |
| amarsh04 | cousin_luigi - ceres | 13:12 |
| cousin_luigi | amarsh04: Possibly #devuan-dev then? | 13:14 |
| amarsh04 | thanks | 13:20 |
| rwp | Xenguy, rrq, I describe it like that, malicious local agents, because on a personal laptop where there is only one user and it only operates on the coffee table on a protected LAN then there is little worry about an attacker breaking the system. Trying to keep it in perspective. | 21:55 |
| rwp | But for an OS distribution which will be run in all types of environments then there will be all types of complaints about security of the default configuration. The default configuration should be secure by default. | 21:55 |
| rwp | That's harder to do in the absolutely general case than it at first appears. | 21:56 |
| rwp | Meanwhile... I am running tmpreaper on my systems and I have configured it to expire files from both /tmp and /var/tmp after they age sufficiently to make them old files that should be removed automatically. | 21:56 |
| Xenguy | rwp, Interesting, first I've heard of tmpreaper | 22:08 |
| rwp | Removing files from random users in a tmp directory is somewhat tricky-hard. I think the process should become the uid of the owner of the file before attempting the unlink action. That seems like it would have the best chance at avoiding being gamed. | 22:12 |
| rwp | It's never just a single file though. It's a possible entire deep tree of files. And that's also tricky. | 22:13 |
| rwp | That's where the new openat*() set of library functions have now taken everything over. | 22:13 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!