Logs: liberachat/#xmonad
| 2022-04-08 13:01:04 | <abastro[m]> | * Like wha |
| 2022-04-08 13:01:07 | <pantsu> | partly anyway, its how they can do the memory management without driving the users insane |
| 2022-04-08 13:01:13 | <abastro[m]> | Oh, that and gtk being singlethreaded |
| 2022-04-08 13:01:35 | <abastro[m]> | Oh, memory management |
| 2022-04-08 13:01:38 | <pantsu> | that isn't stricly true |
| 2022-04-08 13:01:44 | <abastro[m]> | I guess one written in rust could be wildly different then |
| 2022-04-08 13:01:54 | <geekosaur> | note that singlethreaded actually derives from X11 |
| 2022-04-08 13:02:08 | <abastro[m]> | Ouch |
| 2022-04-08 13:02:23 | <abastro[m]> | So.. is Xmonad also singlethreaded? |
| 2022-04-08 13:02:27 | <geekosaur> | you have one socket connecting to the server. multiple threads cannot meaningfully listen on that socket for responses from the X server |
| 2022-04-08 13:02:30 | <geekosaur> | yes |
| 2022-04-08 13:02:35 | <pantsu> | the mainloop does support threading etc, it uses callbacks for communication |
| 2022-04-08 13:02:57 | <geekosaur> | well,there are parts that spawn temporary threads but they have to open their own distinct server connections |
| 2022-04-08 13:03:07 | <abastro[m]> | I see, tho I heard that threading with gtk main loop is quite cumbersome |
| 2022-04-08 13:03:08 | <geekosaur> | and can't share state |
| 2022-04-08 13:03:28 | <abastro[m]> | But I see that with x11 it is even more severe |
| 2022-04-08 13:03:59 | <pantsu> | its not that bad really |
| 2022-04-08 13:04:36 | <abastro[m]> | Can you receive and handle inputs in other threads than main? |
| 2022-04-08 13:04:55 | <pantsu> | but it is C after all :p (you can always use another language though, the introspection is pretty damn nice) |
| 2022-04-08 13:05:21 | <geekosaur> | not without some forwarding mechanism, which is why gtk implementations come with such (postAsync and similar) |
| 2022-04-08 13:05:44 | <geekosaur> | or openm your own connection, but again you can't share state in that case |
| 2022-04-08 13:05:48 | <abastro[m]> | So you need forwarding mechanisms.. |
| 2022-04-08 13:06:02 | <geekosaur> | gtk comes with such mechanisms |
| 2022-04-08 13:06:11 | <abastro[m]> | Oh so this limitation again comes from X11 |
| 2022-04-08 13:06:18 | <abastro[m]> | Meh |
| 2022-04-08 13:06:19 | <geekosaur> | it's one reason it's so popular |
| 2022-04-08 13:06:23 | <abastro[m]> | TIL X is bad |
| 2022-04-08 13:06:33 | <geekosaur> | most alternatives will be no better |
| 2022-04-08 13:06:40 | <geekosaur> | \multiplexed I/O is difficult at best |
| 2022-04-08 13:07:08 | <abastro[m]> | Hm why do I feel so bad when programming with gtk then |
| 2022-04-08 13:07:22 | <geekosaur> | and limits you to atomic transactions which often means size limitations, which makes e.g. uploading a pixmap to a server difficult |
| 2022-04-08 13:07:36 | <geekosaur> | C's a lousy language for such things |
| 2022-04-08 13:08:02 | <abastro[m]> | Eh it felt decent enough for making OS |
| 2022-04-08 13:08:04 | <geekosaur> | I don't feel any worseprogramming GTK than programming anything else in C, but I'm kinda inured to it since C was my first language |
| 2022-04-08 13:08:17 | <geekosaur> | but after something like Haskell, oh god does C feel klunky |
| 2022-04-08 13:08:25 | <abastro[m]> | My first language is C as well |
| 2022-04-08 13:08:54 | <YusefAslam[m]> | My first language is Bash LOL |
| 2022-04-08 13:08:59 | <abastro[m]> | And tbh while I feel C to be klunky, it doesn't go that bad when I avoid resorting to inheritance |
| 2022-04-08 13:09:14 | <abastro[m]> | Procedural programming has worked well for me |
| 2022-04-08 13:10:16 | <geekosaur> | well, inheritance in C is just as klunky as the rest of it. but gtk didn't invent that either |
| 2022-04-08 13:10:25 | <geekosaur> | go look at Xt/Xaw sometime |
| 2022-04-08 13:10:42 | <abastro[m]> | Oh I don't even know about Xt soo |
| 2022-04-08 13:11:04 | <geekosaur> | no, it's mostly well forgotten :) |
| 2022-04-08 13:11:09 | <abastro[m]> | Plus, I did feel simulating inheritance in C more problematic than typical C programming |
| 2022-04-08 13:11:19 | <geekosaur> | the poriginal X toolkit. ugly as sin |
| 2022-04-08 13:12:22 | <geekosaur> | come to think of it, Motif was implemented on top of Xt too |
| 2022-04-08 13:12:32 | <geekosaur> | so did the same kind of "inheritance" |
| 2022-04-08 13:13:48 | <abastro[m]> | Like that one toy OS task where there was page "class" with uninitialized page, memory-backed page and file-backed page inheriting it |
| 2022-04-08 13:13:49 | <geekosaur> | GTK's is actually cleaner and mostly safer than the original |
| 2022-04-08 13:14:41 | <geekosaur> | at least you get an assert if you inherit fromthe wrong thing, instead of a core dump |
| 2022-04-08 13:14:43 | <abastro[m]> | Many fields inside the page "class" which is used or not used depending on which "subclass" it resides on |
| 2022-04-08 13:14:47 | <abastro[m]> | It was a nightmare to me |
| 2022-04-08 13:15:15 | <abastro[m]> | Oh, so gtk's implementation of inheritance was at least slightly better |
| 2022-04-08 13:17:01 | <geekosaur> | re pages, that's true even without subclassing |
| 2022-04-08 13:17:28 | <geekosaur> | a zero page has very little associated state, but you still have to tell the MMU about it |
| 2022-04-08 13:17:30 | <abastro[m]> | Well yeah but it got even worse with subclassinf |
| 2022-04-08 13:17:51 | <abastro[m]> | s/subclassinf/subclassing/ |
| 2022-04-08 13:18:33 | <abastro[m]> | I forgot to mention that the "methods" implemented are quite limited, and somehow, general functionality has to go in each of those methods. |
| 2022-04-08 13:19:24 | <abastro[m]> | I am fine with zero page, tho equating anonymous page and file page, then page cache was nightmare |
| 2022-04-08 13:19:56 | <geekosaur> | it is anyway. sounds good in theory, painful to implement in practice |
| 2022-04-08 13:21:51 | <geekosaur> | (was this minix btw? it's been a few years and my book is long gone, to say nothing of the disk that came with it) |
| 2022-04-08 13:22:08 | <abastro[m]> | What is minix? |
| 2022-04-08 13:23:16 | <geekosaur> | https://en.wikipedia.org/wiki/Operating_Systems:_Design_and_Implementation |
| 2022-04-08 13:24:38 | <geekosaur> | quite a few of us bought that book just toget our hands on minix, back in the day. reportedly it also inspired linux torvalds to develop linux |
| 2022-04-08 13:25:49 | <abastro[m]> | Oh, I was more talking about my uni assignment on toy OS dev |
| 2022-04-08 13:25:59 | <geekosaur> | minix was a message-passing microkernel, so while a little slow it was easy to modify and easy to see how all the pieces fit together |
| 2022-04-08 13:26:07 | <geekosaur> | right, minix was such a toy os |
| 2022-04-08 13:26:19 | <geekosaur> | and the book was intended for such courses |
| 2022-04-08 13:26:20 | <abastro[m]> | Took debugging of millions of multithreading bugs |
| 2022-04-08 13:26:35 | <abastro[m]> | What I worked with was pintos |
| 2022-04-08 13:28:28 | <abastro[m]> | I don't know how message-passing kernel would work, but it sounds like it would be easier to work with |
| 2022-04-08 13:29:05 | <geekosaur> | they're mostly slower than traditional kernels but a lot more secure and easier to understand and work with |
| 2022-04-08 13:29:28 | <geekosaur> | windows and macos are both based on message-passing systems |
| 2022-04-08 13:29:45 | <abastro[m]> | Hmm perhaps pintos is also message-passing then? Idk |
| 2022-04-08 13:29:48 | <abastro[m]> | https://pintos-os.org/ |
| 2022-04-08 13:29:54 | <abastro[m]> | ^ what I was talking about |
| 2022-04-08 13:30:35 | <abastro[m]> | Could be smaller than minix, considering how I was able to implement some parts towards working OS in the end |
| 2022-04-08 13:31:57 | <abastro[m]> | Wait, its VM part seems to be largely left out for students to flesh details out |
| 2022-04-08 13:32:19 | <geekosaur> | from the slides it's a traditional architecture, not microkernel |
| 2022-04-08 13:32:44 | <abastro[m]> | What is microkernel? |
| 2022-04-08 13:33:08 | <abastro[m]> | Perhaps I simply read that as "kernel" |
| 2022-04-08 13:33:13 | <abastro[m]> | Traditional architecture? |
| 2022-04-08 13:33:29 | <geekosaur> | in essence you have a tiny fixed scheduler, then the kernel consists of independent processes that communicate with each other (typically via messages) |
| 2022-04-08 13:33:52 | <geekosaur> | a traditional architecture has the kernel as a single large chunk, like linux |
| 2022-04-08 13:34:02 | <abastro[m]> | Oh, I see |
| 2022-04-08 13:34:27 | <abastro[m]> | Microkernel sounds nicer to code in with separation of concerns (tho I have no experience in them) |
| 2022-04-08 13:34:44 | <abastro[m]> | Easier to hack stuff together randomly in traditional architecture |
| 2022-04-08 13:35:35 | <abastro[m]> | Anyway it seems like, instead of letting students to write the virtual memory managenent, the prof decided to write down sh*tty, hard-to-extend code with many limitations and meh inheritance schemes |
| 2022-04-08 13:36:07 | <abastro[m]> | The nicer parts of it seem to come from original pintos code |
| 2022-04-08 13:43:29 | <abastro[m]> | (Sorry for the rant) |
| 2022-04-08 13:55:59 | × | geekosaur quits (~geekosaur@xmonad/geekosaur) (Quit: Leaving) |
| 2022-04-08 13:57:35 | → | geekosaur joins (~geekosaur@xmonad/geekosaur) |
| 2022-04-08 14:17:58 | × | ^[ quits (~user@user//x-8473491) (Ping timeout: 260 seconds) |
| 2022-04-08 14:24:53 | → | ^[ joins (~user@user//x-8473491) |
| 2022-04-08 14:32:47 | × | benin quits (~benin@183.82.204.110) (Quit: The Lounge - https://thelounge.chat) |
| 2022-04-08 15:03:23 | × | lambdabot quits (~lambdabot@haskell/bot/lambdabot) (Ping timeout: 260 seconds) |
| 2022-04-08 15:22:47 | × | Czernobog quits (~Czernobog@user/czernobog) (Ping timeout: 268 seconds) |
| 2022-04-08 15:30:01 | × | jmct_ quits (sid160793@id-160793.tinside.irccloud.com) () |
| 2022-04-08 15:30:20 | → | jmct joins (sid160793@id-160793.tinside.irccloud.com) |
| 2022-04-08 15:39:49 | → | lambdabot joins (~lambdabot@haskell/bot/lambdabot) |
All times are in UTC.