index
previous
2021-06-06    
---------- 2021-06-07 ----------
04: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.

04:54:57 <schillingklaus> i avoid pulse wholesale, as it is also a redhatted beast
04:57:29 <humpelstilzchen[> I don't even have the daemon installed
04: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.
04:59:49 <UsL> as he did a "default" installation just clicking yes to all. Like 97 % out there does.
05:02:34 <schillingklaus> i hate default installations
05:03:48 <UsL> ah, I see debian has a bug for it. From 2009... https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541538
05:05:08 <UsL> That's funny.. Like they really can't be bothered with the plebs
05:07:01 <schillingklaus> poettering can't get bothered with bug reports
05:07:55 <UsL> either can debian it seems.
05:08:48 <UsL> perhaps devuan can illuminate the path to sanity
05:09:17 <UsL> but that would perhaps be a devuan without out PA at all
05:10:52 <schillingklaus> since debian adopted systemd, its maintainers also adopted Poettering's attitude
05:14:15 <jiggie> its poison
05: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"...
05:16:26 <UsL> oh well, I should maybe make a post about it so devuan maintainers can change it.
05:19:11 <Wonka> uh, removing PA from devuan would also remove sound from Chromium and Firefox.
05:19:46 <schillingklaus> there's apulse
05:21:03 <Wonka> ok, didn't know about that.
05:30:12 <luna-is-here> apulse is not working reliably, though. I tried it for some time and it caused a lot of trouble.
05:31:32 <luna-is-here> I'd agreed that "flat-volumes = no" is a sane default.
05:31:40 <luna-is-here> * should be.

06:25:38 <fsmithred> flat-volumes = no is the default in Bullseye/Chimaera

07: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.
07:58:34 <Katje> anyone had issues using a /31 address (ipv4) and the /etc/network/interfaces system ?
08:02:26 <szutt> so you have only two addresses ? the broadcast address and the network ?
08:15:19 <GyrosGeier> no, that has been special-cased
08:15:45 <GyrosGeier> but it depends on the IP stack if that special case is implemented
08:16:15 <GyrosGeier> back when I was a regular on anonet, I used /31 networks for BGP peering and that was fine
08:16:25 <GyrosGeier> but IIRC I configured them with quagga
08:16:41 <GyrosGeier> I don't see why it shouldn't work through ifupdown though

08: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."
08:47:09 <mason> Katje: GyrosGeier: ^
08:47:53 <Katje> had to specify the broad cast as 45.255.255.255
08:47:54 <Katje> works now tho
08: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.
08:52:33 <GyrosGeier> there shouldn't be a broadcast address on those networks at all
08:53:07 <GyrosGeier> IIRC you can just leave it out
08:53:12 <mason> https://datatracker.ietf.org/doc/html/rfc3021 agrees
08:53:58 <mason> Hm, no, I guess section 3.3 says to use 255.255.255.255
08:54:27 <mason> Katje: ^ I'd try that for more potential correctness.
08:54:31 <mason> and hence futureproofing
08:55:26 <Katje> it won't configure the device if you leave the broadcast out
08:56:04 <GyrosGeier> ow
08:56:05 <mason> Katje: No, the RFC is evidently suggesting 255.255.255.255 as a broadcast.
08:57:08 <mason> section 3.3, talking about amending https://datatracker.ietf.org/doc/html/rfc2644
09:20:55 <Katje> mason: thanks
09:20:56 <Katje> will ifx
09: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.
09:22:10 <Katje> will do
09: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?
09:52:46 <Katje> export http_proxy ?
09:54:32 <UsL> will that set it for all my stuff? I only want kynx to use proxy. Not wget or curl for example
09:54:41 <UsL> *lynkx
09:54:45 <UsL> ...
09:55:48 <UsL> or is there a better ncurses browser perhaps that makes sense.. I didn't think to look for that yet.
09:56:08 <schillingklaus> maybe w3m
09:57:11 <UsL> thanks. I'll look into it
10: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.
10: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.
10:36:01 <sadsnork> UsL, could you start w3m [or lynx] with "export http_proxy=blahblah && w3m" and then it only applies to that browser?
10:41:53 <UsL> well, that did somethng. But gave me: "lynx: Can't access startfile"
10:42:29 <sadsnork> ohhh, is that because you need to specify the url on the command line?
10: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
10:44:41 <user__> What's the latest security update about? Reading headlines, something about Debian updates?
10:45:18 <user__> Reading lwn.net: SEVEN new kernels? Wow?
10:45:34 <user__> Do they really maintain seven kernels in parallel?
10:53:59 <user__> [yes they do?!]
11: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?
11: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...
2021-06-07    
search in #devuan logs:
index
next