Logs: liberachat/#xmonad
| 2023-10-22 19:19:56 | <haskellbridge> | <Tranquil Ity> I prefer Matrix over all else as it's a really competent protocol that still remains very simple (and in my opinion simpler to actually *interact with* than IRC, less ambiguity) |
| 2023-10-22 19:21:42 | <geekosaur> | https://libera.chat/guides/connect#accessing-liberachat-via-tor |
| 2023-10-22 19:22:24 | × | defjam quits (~defjam@2a02:c7e:2807:b900:50f8:a906:7e67:c666) (Ping timeout: 272 seconds) |
| 2023-10-22 19:22:34 | <geekosaur> | tl;dr: use their Tor endpoint and auth via SASL |
| 2023-10-22 19:23:00 | <geekosaur> | MapAddress palladium.libera.chat libera75jm6of4wxpxt4aynol3xjmbtxgfyjpu34ss4d7r7q2v5zrpyd.onion |
| 2023-10-22 19:23:18 | <geekosaur> | oh, specifically pubkey SASL, not PLAIN |
| 2023-10-22 19:24:20 | <haskellbridge> | <Tranquil Ity> Did they change something recently? Last time I tried it at the start of this year, it was a broken cycle of *if you want to register you need to register* |
| 2023-10-22 19:26:41 | <geekosaur> | I think you need to do something silly like use webchat to initially connect and register |
| 2023-10-22 19:28:08 | <haskellbridge> | <Tranquil Ity> Iirc webchat blocked registration through Tor |
| 2023-10-22 19:32:06 | <geekosaur> | hm. Guess you'll have to discuss it with them (in #libera); the instructions for setting up a cert indeed assume you have created an account some other way first, which would preclude Tor |
| 2023-10-22 19:33:12 | → | defjam joins (~defjam@2a02:c7e:2807:b900:50f8:a906:7e67:c666) |
| 2023-10-22 19:37:56 | <haskellbridge> | <Tranquil Ity> Hard to access #libera without being able to access libera.chat :D |
| 2023-10-22 19:37:57 | <haskellbridge> | <Tranquil Ity> A few people told me "it's to prevent spam", or something like that, which, frankly, I do not think is a valid reason to prevent people from accessing the service fully anonymously, and only allowing it for users that at least once accessed it non anonymously. |
| 2023-10-22 19:37:58 | <haskellbridge> | <Tranquil Ity> Personally I find it a bit shady, especially the way it's not clear from their documentation that it's the case, and overall, I am not a fan of this way of doing things. Blocking Tor is always a huge red flag for any service. Why do they want my home IP? Why do they wanna know where I live?What do they need it for? |
| 2023-10-22 19:39:21 | × | defjam quits (~defjam@2a02:c7e:2807:b900:50f8:a906:7e67:c666) (Ping timeout: 260 seconds) |
| 2023-10-22 19:50:14 | → | defjam joins (~defjam@2a02:c7e:2807:b900:50f8:a906:7e67:c666) |
| 2023-10-22 19:56:11 | × | defjam quits (~defjam@2a02:c7e:2807:b900:50f8:a906:7e67:c666) (Ping timeout: 255 seconds) |
| 2023-10-22 20:09:53 | → | defjam joins (~defjam@2a02:c7e:2807:b900:50f8:a906:7e67:c666) |
| 2023-10-22 20:15:14 | × | defjam quits (~defjam@2a02:c7e:2807:b900:50f8:a906:7e67:c666) (Ping timeout: 258 seconds) |
| 2023-10-22 20:26:52 | → | defjam joins (~defjam@2a02:c7e:2807:b900:50f8:a906:7e67:c666) |
| 2023-10-22 20:27:47 | <liskin> | They probably don't care about any of that. |
| 2023-10-22 20:28:15 | <liskin> | It just makes it easier to fight spam if they don't go the extra mile to allow fully anonymous access. |
| 2023-10-22 20:29:46 | <liskin> | Back to the Wayland question - no I don't mean just config in Haskell. I mean the whole window manager as a separate process, written in Haskell, talking to a compositor written in a non-GC language, using some sort of protocol we'd need to invent for it |
| 2023-10-22 20:30:47 | <liskin> | Perhaps the non-GC thing isn't that I much of a requirement, dunno, but the separate process thing seems useful |
| 2023-10-22 20:31:34 | <liskin> | You want to be able to restart the WM when tweaking your config without having to restart the compositor, and thus your entire graphical session |
| 2023-10-22 20:31:36 | <geekosaur> | sadly I'm not sure that is possible in Wayland's permissions model. some things a WM needs are only accessible by the compositor, apparently |
| 2023-10-22 20:31:53 | <liskin> | geekosaur: it's absolutely possible |
| 2023-10-22 20:32:12 | <liskin> | If you program the compositor you can do literally everything you want |
| 2023-10-22 20:32:30 | <haskellbridge> | <Tranquil Ity> Hmm, I think it might be possible to dynamically load the config as a shared library rather than as a process |
| 2023-10-22 20:32:52 | <haskellbridge> | <Tranquil Ity> Would be faster to do things + would allow for quick reloads |
| 2023-10-22 20:33:08 | × | defjam quits (~defjam@2a02:c7e:2807:b900:50f8:a906:7e67:c666) (Ping timeout: 260 seconds) |
| 2023-10-22 20:33:19 | <liskin> | If you don't mind the occasional crash then yeah, you could do that |
| 2023-10-22 20:33:20 | <haskellbridge> | <Tranquil Ity> (Also the entire compositor can be replaced in in-place with some Wayland protocol apparently) |
| 2023-10-22 20:33:39 | <haskellbridge> | <Tranquil Ity> Can probably catch a crash I think |
| 2023-10-22 20:33:45 | <liskin> | Oh, did they already solve the restart issue? |
| 2023-10-22 20:34:00 | <haskellbridge> | <Tranquil Ity> There's been talk about it last year |
| 2023-10-22 20:34:09 | <liskin> | Yeah, talk I've seen |
| 2023-10-22 20:34:42 | <haskellbridge> | <Tranquil Ity> A protocol exists, which has been getting implemented into major DEs |
| 2023-10-22 20:34:43 | <haskellbridge> | <Tranquil Ity> I am unsure of the current state, I presume it's resolved, as sway can restart in place for example |
| 2023-10-22 20:35:20 | <liskin> | That does make things easier then |
| 2023-10-22 20:35:44 | <haskellbridge> | <Tranquil Ity> I will look into that I guess, though I think the only use would be updating without needing to restart the session, as crashes should be catchable if I am not mistaken |
| 2023-10-22 20:36:18 | × | catman quits (~catman@user/catman) (Quit: WeeChat 4.2.0-dev) |
| 2023-10-22 20:36:41 | → | catman joins (~catman@user/catman) |
| 2023-10-22 20:37:03 | → | defjam joins (~defjam@2a02:c7e:2807:b900:50f8:a906:7e67:c666) |
| 2023-10-22 20:37:31 | <liskin> | You're not meant to catch a SEGV really |
| 2023-10-22 20:38:23 | <liskin> | And what happens if you evaluate error/undefined in Haskell being called from C, I don't know. Presumably you could wrap everything in a wrapper that does catch that |
| 2023-10-22 20:39:10 | <liskin> | I still don't quite understand why don't we just use a separate process. It's how Unix stuff was meant to work, for decades now |
| 2023-10-22 20:39:40 | <liskin> | It just means using rpc instead of ffi |
| 2023-10-22 20:40:23 | <haskellbridge> | <Tranquil Ity> That is true, but I think it should be fine. It's worth a try, at least. |
| 2023-10-22 20:40:25 | <haskellbridge> | <Tranquil Ity> Unfortunately I never did FFI with HS yet, most of what I did was implementing random small programs. |
| 2023-10-22 20:40:26 | <haskellbridge> | <Tranquil Ity> Sure, but it has relatively high overhead, for something you want to have as little overhead as possible |
| 2023-10-22 20:41:02 | <haskellbridge> | <Tranquil Ity> It would restrict the protocol architecture quite a lot, without that much benefit, in my opinion |
| 2023-10-22 20:48:55 | <haskellbridge> | <Tranquil Ity> Uploading resources from the Haskell code to the compositor server, for example, would be quite slow, which would complicate the design and implementation of things. I think I want the thing to be as flexible as reasonably possible. |
| 2023-10-22 20:51:31 | <haskellbridge> | <Tranquil Ity> That is true, but I think it should be fine. It's worth a try, at least. |
| 2023-10-22 20:51:31 | <haskellbridge> | <Tranquil Ity> Unfortunately I never did FFI with HS yet, most of what I did was implementing random small programs (a socket server, a parser combinators "library", and two STLC inference algos) |
| 2023-10-22 20:51:33 | <haskellbridge> | <Tranquil Ity> Sure, but it has relatively high overhead, for something you want to have as little overhead as possible |
| 2023-10-22 20:54:25 | <geekosaur> | of course these days the things one would think should have low overhead communicate via dbus… |
| 2023-10-22 20:57:23 | <haskellbridge> | <Tranquil Ity> I do not think dragging in any more dependencies than necessary, especially something as heavy and controversial as dbus, is wise |
| 2023-10-22 20:57:24 | <haskellbridge> | <Tranquil Ity> Besides, doesn't dbus use a socket? |
| 2023-10-22 20:58:54 | <liskin> | I don't quite agree about the "slow" claim |
| 2023-10-22 21:00:32 | <liskin> | In 2012 I implemented a thing that grabbed a full screen image from one X server and draw it on another, as that was the only way to support multi-GPU laptops where some outputs were wired to differents GPUs. You couldn't notice any slowdown. |
| 2023-10-22 21:01:29 | <liskin> | Doing a similar thing 10 years later, and also definitely not for every frame, would be unnoticeable. |
| 2023-10-22 21:01:44 | <liskin> | And also, shared memory exists. |
| 2023-10-22 21:02:38 | <liskin> | Even if we used dbus for the protocol, I bet nobody would notice any slowdown. |
| 2023-10-22 21:02:50 | <liskin> | But we could just use the Wayland protocol itself... |
| 2023-10-22 21:03:14 | <liskin> | (although that would mean we'd need a Haskell impl of it) |
| 2023-10-22 21:05:10 | <haskellbridge> | <Tranquil Ity> It's slower than direct calls or shm, as it all has to go through the kernel's network stack afaik, and only has access to the ancient read/write. |
| 2023-10-22 21:05:10 | <haskellbridge> | <Tranquil Ity> Ofc it'd need benchmarks and testing. |
| 2023-10-22 21:05:12 | <haskellbridge> | <Tranquil Ity> X11 has shm facilities now, which afaik are used for a lot of things now (high performance rendering included) |
| 2023-10-22 21:05:13 | <haskellbridge> | <Tranquil Ity> Yea, I also thought if that, which is why I think it's better to do a shared lib load. Doing the impl in Haskell is going back to core modules in C, compositor in Haskell. Which will need the in place restart interface I guess. I don't think it should have to be brought down for that though. |
| 2023-10-22 21:05:14 | <haskellbridge> | <Tranquil Ity> Well, I dunno :P |
| 2023-10-22 21:05:16 | <haskellbridge> | <Tranquil Ity> I'll have to head offline now, I'll read any messages in the morning! Was very nice talking, and I am looking forward to this! |
| 2023-10-22 21:07:32 | × | td_ quits (~td@i53870939.versanet.de) (Ping timeout: 272 seconds) |
| 2023-10-22 21:21:45 | <geekosaur> | there's a deprecated binding of the C Wayland protocol library, but it's deprecated because the author started on (and apparently never finished) a newer version |
| 2023-10-22 21:22:14 | <geekosaur> | of course ideally we'd have a native implementation à la xhb |
| 2023-10-22 21:24:10 | → | td_ joins (~td@i5387091E.versanet.de) |
| 2023-10-22 21:24:13 | <geekosaur> | (it looks like waymonad-scanner might generate such bindings? is ongy still around?) |
| 2023-10-22 21:24:21 | <geekosaur> | (last commit was in August) |
| 2023-10-22 21:28:40 | × | td_ quits (~td@i5387091E.versanet.de) (Ping timeout: 255 seconds) |
| 2023-10-22 21:42:55 | × | defjam quits (~defjam@2a02:c7e:2807:b900:50f8:a906:7e67:c666) (Ping timeout: 264 seconds) |
| 2023-10-22 21:45:23 | → | td_ joins (~td@i5387090E.versanet.de) |
| 2023-10-22 21:50:15 | → | defjam joins (~defjam@2a02:c7e:2807:b900:50f8:a906:7e67:c666) |
| 2023-10-22 21:50:56 | × | td_ quits (~td@i5387090E.versanet.de) (Ping timeout: 255 seconds) |
| 2023-10-22 21:52:37 | → | td_ joins (~td@i53870910.versanet.de) |
| 2023-10-22 22:03:59 | × | td_ quits (~td@i53870910.versanet.de) (Ping timeout: 255 seconds) |
| 2023-10-22 22:05:57 | → | td_ joins (~td@i5387093D.versanet.de) |
| 2023-10-22 23:13:40 | × | tv quits (~tv@user/tv) (Read error: Connection reset by peer) |
| 2023-10-22 23:32:13 | → | tv joins (~tv@user/tv) |
| 2023-10-22 23:32:39 | × | td_ quits (~td@i5387093D.versanet.de) (Ping timeout: 240 seconds) |
| 2023-10-22 23:34:31 | → | td_ joins (~td@i5387090A.versanet.de) |
| 2023-10-23 00:22:27 | × | catman quits (~catman@user/catman) (Quit: WeeChat 4.2.0-dev) |
| 2023-10-23 00:29:33 | → | catman joins (~catman@user/catman) |
| 2023-10-23 03:03:28 | × | td_ quits (~td@i5387090A.versanet.de) (Ping timeout: 272 seconds) |
| 2023-10-23 03:05:05 | → | td_ joins (~td@i53870920.versanet.de) |
| 2023-10-23 05:26:55 | × | catman quits (~catman@user/catman) (Quit: WeeChat 4.2.0-dev) |
| 2023-10-23 05:27:16 | → | catman joins (~catman@user/catman) |
| 2023-10-23 06:17:43 | × | ft quits (~ft@p4fc2a529.dip0.t-ipconnect.de) (Quit: leaving) |
| 2023-10-23 09:23:07 | → | derfflinger joins (~derffling@user/derfflinger) |
| 2023-10-23 10:21:38 | × | td_ quits (~td@i53870920.versanet.de) (Ping timeout: 258 seconds) |
| 2023-10-23 10:23:51 | <haskellbridge> | <Tranquil Ity> The Wayland protocol is pretty simple, what's hard is the stuff it needs to have done around it, such as display modesetting, input gathering and propagation, and the actual composition. |
All times are in UTC.