18:52:15 <UsL> is devuan still using "flat-volumes = yes" in pulse audio daemon conf file, btw? I think the user friendly setting "flat-volumes = no" should be standard. Since devuan defaults to use PA anyway.
18:54:57 <schillingklaus> i avoid pulse wholesale, as it is also a redhatted beast
18:57:29 <humpelstilzchen[> I don't even have the daemon installed
18:58:37 <UsL> granted, but as a default setting it should be "flat-volumes = no" I think. I recommended devuan to a friend and he was happy until kodi blew his ears out.
18:59:49 <UsL> as he did a "default" installation just clicking yes to all. Like 97 % out there does.
19:02:34 <schillingklaus> i hate default installations
19:03:48 <UsL> ah, I see debian has a bug for it. From 2009... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541538
19:05:08 <UsL> That's funny.. Like they really can't be bothered with the plebs
19:07:01 <schillingklaus> poettering can't get bothered with bug reports
19:07:55 <UsL> either can debian it seems.
19:08:48 <UsL> perhaps devuan can illuminate the path to sanity
19:09:17 <UsL> but that would perhaps be a devuan without out PA at all
19:10:52 <schillingklaus> since debian adopted systemd, its maintainers also adopted Poettering's attitude
19:14:15 <jiggie> its poison
19:15:36 <UsL> even more the reason devuan should use flat-volumes = no. Found a rant: https://old.reddit.com/r/linux/comments/2rjiaa/horrible_decisions_flat_volumes_in_pulseaudio_a/ Some of the examples are pretty scary. Loosing some of your hearing because "poettering"...
19:16:26 <UsL> oh well, I should maybe make a post about it so devuan maintainers can change it.
19:19:11 <Wonka> uh, removing PA from devuan would also remove sound from Chromium and Firefox.
19:19:46 <schillingklaus> there's apulse
19:21:03 <Wonka> ok, didn't know about that.
19:30:12 <luna-is-here> apulse is not working reliably, though. I tried it for some time and it caused a lot of trouble.
19:31:32 <luna-is-here> I'd agreed that "flat-volumes = no" is a sane default.
19:31:40 <luna-is-here> * should be.
20:25:38 <fsmithred> flat-volumes = no is the default in Bullseye/Chimaera
21:50:32 <UsL> fsmithred: that's good to hear! (about flat-volumes = no, I got disconnected). I explained it to my friend and he wondered about alternative audio mixers and I said I only knew about jack but that I hadn't used it.
21:58:34 <Katje> anyone had issues using a /31 address (ipv4) and the /etc/network/interfaces system ?
22:02:26 <szutt> so you have only two addresses ? the broadcast address and the network ?
22:15:19 <GyrosGeier> no, that has been special-cased
22:15:45 <GyrosGeier> but it depends on the IP stack if that special case is implemented
22:16:15 <GyrosGeier> back when I was a regular on anonet, I used /31 networks for BGP peering and that was fine
22:16:25 <GyrosGeier> but IIRC I configured them with quagga
22:16:41 <GyrosGeier> I don't see why it shouldn't work through ifupdown though
22:47:01 <mason> Interesting: https://docs.netgate.com/pfsense/en/latest/network/cidr.html "The use of /31 networks is a special case defined by RFC 3021 where the two IP addresses in the subnet are usable for point-to-point links to conserve IPv4 address space. Not all operating systems support RFC 3021, so use it with caution."
22:47:09 <mason> Katje: GyrosGeier: ^
22:47:53 <Katje> had to specify the broad cast as 22.214.171.124
22:47:54 <Katje> works now tho
22:49:59 <mason> Katje: That's interesting and a bit weird. Be worth exploring whether it's intended in De*an. Having to specify a funny broadcast when the subnet doesn't have space for one would make me nervous.
22:52:33 <GyrosGeier> there shouldn't be a broadcast address on those networks at all
22:53:07 <GyrosGeier> IIRC you can just leave it out
22:53:12 <mason> https://datatracker.ietf.org/doc/html/rfc3021 agrees
22:53:58 <mason> Hm, no, I guess section 3.3 says to use 255.255.255.255
22:54:27 <mason> Katje: ^ I'd try that for more potential correctness.
22:54:31 <mason> and hence futureproofing
22:55:26 <Katje> it won't configure the device if you leave the broadcast out
22:56:05 <mason> Katje: No, the RFC is evidently suggesting 255.255.255.255 as a broadcast.
22:57:08 <mason> section 3.3, talking about amending https://datatracker.ietf.org/doc/html/rfc2644
23:20:55 <Katje> mason: thanks
23:20:56 <Katje> will ifx
23:21:43 <mason> Katje: Test anyway. It seems like it'd be the correct broadcast address based on what I linked, but that doesn't strictly mean it'd work. But it's worth testing.
23:47:19 <UsL> why is lynx so hard to setup? I'm trying to set it to use a proxy but whatever I try it will not use it. I've set ~/.lynxrc to use http(s)_proxy:127.0.0.1/localhost:numbers/port to no avail. I tested what I guess is an old method of putting /etc/lynx-sites.cfg with the same parameters in lynxrc. Nothing works. Does anyone have some experience with this?
23:52:46 <Katje> export http_proxy ?
23:54:32 <UsL> will that set it for all my stuff? I only want kynx to use proxy. Not wget or curl for example
23:55:48 <UsL> or is there a better ncurses browser perhaps that makes sense.. I didn't think to look for that yet.
23:56:08 <schillingklaus> maybe w3m
23:57:11 <UsL> thanks. I'll look into it
---------- 2021-06-07 ----------
00:18:03 <UsL> seems like w3m only does if environment is set to it. I guess I can give up on this. I'm not too keen to set my environment to globally use a Tor exit node if I can't control what will use it if that environment variable is set.
00:33:22 <UsL> makes me mad that setting "http_proxy:http://your.proxy.com:8080 to C:\Program Files (x86)\Lynx - web browser\lynx.cfg" works great for windows users. Good for them. Is lynx made for windows perhaps.
00:36:01 <sadsnork> UsL, could you start w3m [or lynx] with "export http_proxy=blahblah && w3m" and then it only applies to that browser?
00:41:53 <UsL> well, that did somethng. But gave me: "lynx: Can't access startfile"
00:42:29 <sadsnork> ohhh, is that because you need to specify the url on the command line?
00:44:34 <UsL> I guess so. SO, that is perhaps not ideal.. I guess I could do a switch for the environment to set http_ https_ on and off. Seems like the viable thing left to do
00:44:41 <user__> What's the latest security update about? Reading headlines, something about Debian updates?
00:45:18 <user__> Reading lwn.net: SEVEN new kernels? Wow?
00:45:34 <user__> Do they really maintain seven kernels in parallel?
00:53:59 <user__> [yes they do?!]
01:20:15 <pitriss> UsL: and how about creating alias in your shell config with "http_proxy=blahblah lynx" so it will always pass correct proxy variable just for that one command?
01:37:22 <UsL> yes, thanks. I am investigating which method would suit me best. Aliases or setting a switch for environment or what not. Well, the best would of course for .lunxrc do actually do what it claims here: https://lynx.invisible-island.net/lynx2.8.5/lynx_help/body.html#HTTP_PROXY but as that seems not to work for me in anyway or iteration...