Search logs:

channel logs for 2004 - 2010 are archived at http://tunes.org/~nef/logs/old/ ·· can't be searched

#osdev2 = #osdev @ Libera from 23may2021 to present

#osdev @ OPN/FreeNode from 3apr2001 to 23may2021

all other channels are on OPN/FreeNode from 2004 to present


http://bespin.org/~qz/search/?view=1&c=osdev2&y=21&m=11&d=26

Friday, 26 November 2021

00:22:00 <kazinsal> for those who like weird technical references and the NT kernel, Windows Internals 7th Edition Part 2 has been published
00:23:00 <sonny> same guys?
00:23:00 <kazinsal> yep
00:23:00 <kaichiuchu> excellent
00:23:00 <kazinsal> ooh, it's got 200 pages on NTFS and the disk caching subsystem
00:23:00 <kaichiuchu> do you have a link or is this something I should be googling for
00:24:00 <kazinsal> https://www.microsoftpressstore.com/store/windows-internals-part-2-9780135462331
00:24:00 <bslsk05> ​www.microsoftpressstore.com: Windows Internals, Part 2, 7th Edition | Microsoft Press Store
00:24:00 <kaichiuchu> thanks
00:24:00 <kazinsal> I only realized this because they're having a big sale
00:24:00 <kazinsal> buy two or more books or ebooks and use the discount code BOOKSGIVING at checkout for 55% off your subtotal
00:25:00 <kazinsal> boss told me yesterday we needed more Azure certs so I went to the microsoft press store to see what the cost of Azure cert books was like and saw that
00:25:00 <kazinsal> thought, heck, why not
01:27:00 <sonny> I'll probably get it
04:04:00 <klange> Time to go through all my source files and clean them up in preparation for 2.0...
04:05:00 <klange> Gotta make sure everything is updated to the javadoc-style leading comments, remove all the vim hints (why are there new files from after I fully switched to bim that still have those?), make sure everything has an approprate copyright notice...
04:24:00 <Ameisen> geist: both compilers
04:24:00 <Ameisen> (Was at in-laws)
04:25:00 <Ameisen> mind that it is dependent on coroutines (which isn't solid in either compiler yet) and a third-party lib to provide the generator class
05:52:00 <geist> yah i had a ton of people at my place all day
06:22:00 <amazigh> hello, what emulator do you recommend do get into osdev?
06:22:00 <klange> all of them
06:23:00 <amazigh> I was looking for a small machine emulator, like 8bit thing, but none has network support.
06:23:00 <kazinsal> qemu to rapidly test builds, VMware to test enterprise virtualization, real hardware to test performance
06:23:00 <klange> I wouldn't get into osdev by targetting small embedded machines - most of them were never intended to run anything akin to an operating system
06:24:00 <amazigh> I go the qemu route, then amd64 arch for the CPU is the way to go?
06:24:00 <klange> x86-64 is definitely top of _my_ list of suggestions, and I spend most of my time with QEMU
06:25:00 <amazigh> I am really a newbie, hence I struggle to find something to start with, any help?
06:25:00 <klange> wiki.osdev.org
06:25:00 <amazigh> I mean what task can I do to get started?
06:25:00 * amazigh looking at the wiki
06:26:00 <klange> There's whole articles there about things to do to get started.
06:26:00 <moon-child> amazigh: ohai
06:27:00 <kazinsal> we really at some point ought to refresh some of the beginner tutorials. maybe once I do the whole "64-bit kernel rewrite" thing I'll spend some time on that
06:27:00 <kazinsal> there's still some atrocities in the "getting started" department
06:28:00 <klange> Personal opinions: 1) Target x86-64 to start. There's so much more community documentation than for anything else. Aarch64 and RiscV are cool things, but the references just aren't there.
06:29:00 <kazinsal> And the physical presence of platforms you can osdev on.
06:29:00 <klange> 2) Don't write a bootloader. At least to start. There's now several viable boot environments you can use to get up and running and bootloaders are just an exercise in legacy cruft.
06:29:00 <kazinsal> thank you for the reminder that I need to find a bootloader that'll do 64-bit ELFs over TFTP
06:30:00 <geist> okay, so time to write a bootloader!
06:30:00 <kazinsal> ha!
06:30:00 <geist> somewhere i still have a NE2000 card that has a load off tftp rom in it
06:30:00 <geist> was kinda nice
06:30:00 <geist> no idea where it came from
06:30:00 <klange> If you slap a multiboot1-with-aout-kludge header in it, there's a PXE multiboot loader that should work.
06:31:00 <klange> Though, uh, you'll need a longmode bootstrap.
06:31:00 <kazinsal> yeah, right now I have GRUB doing the PXE boot
06:31:00 <geist> amazigh: yah what klange said. 8 bit is a bit low, hard to build much of a complex modern system with it, though you can but you'll be fighting assembly and whatnot more than anything esle
06:31:00 <klange> GRUB will also happily load 64-bit ELFs as multiboot2 correctly, though again - need a longmode bootstrap as it still will put you in protected.
06:31:00 <geist> but, say 32bit cortex-m class ARM stuff you can do a proper preemptive OS on if you want
06:32:00 <moon-child> kazinsal: I think filling in the gaps might be more valuable. I feel like a _lot_ of people say 'I finished barebones; now what?'
06:35:00 <klange> 3) "What emulator should I use?" All of them. Run your OS in everything you can get your hands on. I even test my OS in Bochs _which takes several minutes to boot it_. QEMU, VirtualBox, VMWare Workstation - use 'em all.
06:35:00 <amazigh> ok got that
06:35:00 <geist> though to be fair when just getting started out having a single emulator is pretty useful
06:35:00 <geist> yes yes you shoudl run it on everything yes, but that's a bit of a tall ask for someone just getting started
06:35:00 <geist> also presumes you're on x86 where there *are* multiple emulators
06:36:00 <klange> It's been a looong time since it was relevant to me, but I recall Bochs has very good tools for the super low level early debugging.
06:36:00 <geist> for most other arches there are a lot less options
06:39:00 <geist> though i guess you did recommend x86-64
06:40:00 <klange> qemu would be the best universal choice, I imagine
06:46:00 <amazigh> The wiki sounds great (I was told osdev wiki was not great..)
06:47:00 <amazigh> Someone recommended me to read on bsd kernel code, instead.
06:47:00 <amazigh> (sorry for the noise!)
06:47:00 <klange> Reading code for a large project is not a great way to learn. And I say that as someone whose primarily goal with my project is to have a large project for people to read to learn...
06:48:00 <amazigh> Anyway, going through OS from 0 to 1.
06:48:00 <amazigh> (the book)
06:48:00 <amazigh> moon-child: hey
07:58:00 <gorgonical_> For the life of me can't figure out why linux won't take an interrupt on arm64. All my understanding of the arm virtual interrupt system says it should be
07:58:00 <gorgonical_> But it doesn't
07:58:00 <gorgonical_> :(
08:05:00 <gorgonical_> Is there anything I should be checking? The hypervisor marks hcr_el2.vi, and hcr_el2.imo is on, so it should be delivering them. Linux for it's part doesn't have interrupts masked but I never get a message showing that it took the interrupt and the hypervisor still shows it as pending
08:31:00 <geist> hmm, what class of interrupt is it?
11:06:00 <j`ey> gog: you said you know about ELF right? I have an elf sym.. but im not sure how I find the code associated with that?
11:07:00 <j`ey> st_value as an offset from the section its in?
11:10:00 <klange> What kind of ELF do you have?
11:10:00 <j`ey> elf64
11:10:00 <klange> I mean what kind of object is
11:11:00 <j`ey> oh, currently Im messing around with a .o, elf 64 relocatable
11:12:00 <j`ey> although the plan is to eventually work on an executable
11:13:00 <klange> Every symbol has an st_shndx with the section it belongs to. If that is an actual section and not UNDEF or something implementation-specific, then st_value should be added to the relevant section's sh_addr.
11:14:00 <j`ey> and that's the offset in the elf file?
11:14:00 <klange> Eh, depends.
11:15:00 <klange> Actually I should say "absolutely not".
11:15:00 <klange> sh_offset is the offset into the file
11:15:00 <j`ey> :D
11:15:00 <klange> sh_addr you are supposed to fill in with the actual address
11:16:00 <klange> And similarly you are supposed to put the final symbol address into st_value for the symbols.
11:16:00 <j`ey> I'm not trying to load this to run it, I'm trying to do some analysis
11:16:00 <j`ey> on the machine code
11:16:00 <klange> If you have a NOBITS section, then sh_addr (and sh_offset) should be unset and you need to allocate space for them
11:17:00 <klange> Ah, well, have you ever tried to look at an object file with, say, objdump?
11:17:00 <klange> And noticed that all sorts of stuff looks weird and sometimes outright wrong?
11:18:00 <j`ey> whys that?
11:18:00 <klange> You kinda need to perform relocations for some code to make any sense or it'll all be meaningless zeros or sometimes offsets (though x86-64 you tend to get zeros - x86-32 tended to have values in the code because you'd get more relocations that use "value currently there")
11:19:00 <klange> x86-64 output, at least from binutils, prefers relocations with addends where the values come with the relocations rather than being in the place where the relocation goes
11:19:00 <j`ey> hmm
11:20:00 <j`ey> I didnt consider having to apply relocation
11:25:00 <j`ey> well I can get an instruction out now, that's cool
11:26:00 <klange> this is my relocatable object linker: https://github.com/klange/toaruos/blob/master/kernel/misc/elf64.c#L42
11:26:00 <bslsk05> ​github.com: toaruos/elf64.c at master · klange/toaruos · GitHub
11:29:00 <klange> so much nicer than my old one which is an absolute mess https://github.com/klange/toaruos/blob/v1.14.1/kernel/sys/module.c
11:29:00 <bslsk05> ​github.com: toaruos/module.c at v1.14.1 · klange/toaruos · GitHub
11:31:00 <j`ey> will have a look, t
11:31:00 <j`ey> y
11:32:00 <j`ey> I can print out all the insts of a function/symbol now
11:40:00 <j`ey> ah yes, clearly I need to relocate or something, all the branch instructions are 'bl 0'
11:41:00 <klange> yep :D
11:42:00 <klange> for stuff local to the object, section offset + symbol value should be fine
11:42:00 <klange> for UNDEF (external stuff), I would just assign a random unique address
11:43:00 <klange> and then Elf64 relocatable objects should only have a couple of different kinds of relocations and they're all pretty straightforward
11:43:00 <klange> they're arch-dependent, so if you're doing arm they'll be different values than the x86-64 stuff, but probably still the same basic "write 32-bit value, write 64-bit value, write some value with offset from the address..."
11:44:00 <j`ey> I think the Linux kernel only uses one, which is the write some value to some address
11:44:00 <klange> I have no idea how they're controlling that, I've seen three types out of my object files
11:45:00 <j`ey> only R_AARCH64_RELATIVE is handled
11:45:00 <klange> oh, you know, it could be because _32 only shows up in debug sections, and _PC32 only shows up in eh_frames...
11:46:00 <j`ey> https://github.com/torvalds/linux/blob/master/arch/arm64/kernel/head.S#L766
11:46:00 <bslsk05> ​github.com: linux/head.S at master · torvalds/linux · GitHub
11:46:00 <klange> I do see my actual text sections only have R_X86_64_64
11:56:00 <klange> Ah, there it goes, was wondering when that would happen.
12:06:00 <j`ey> oh, I see the virtual address values now, when I run my program on the executable (not just the .o)
12:06:00 <j`ey> (and it crashes because im using st_value as an offset..)
12:09:00 <j`ey> so now I need to understand how to get the file offset, instead of that virtual address
12:14:00 <j`ey> oh, I think I can subtract the st_value from the sh_addr of the section its in
15:09:00 <j`ey> sweet, I need to veryify it more, but it looks like my tool can, starting with a certain function, find all the functions that it transitively calls
15:11:00 <zid> I ran my OS. It page faulted.
15:11:00 <zid> My breakpoint on my page fault handler refuses to hit.
15:11:00 <zid> I gave up
16:59:00 <ornxka> anyone used the CLINT register for qemu riscv64? whenever i set mtimecmp to (uint64_t)-1 it generates interrupts continuously
17:13:00 <ornxka> when i set it to eg 0xCFFFFFFFFFFFFFFF, i dont get an interrupt, but for -1 i get things like info: timer interrupt: mtime=0x0000000000EF3BD0, mtimecmp=0xFFFFFFFFFFFFFFFF
17:36:00 <riv> will there be another qemu advent calendar?
19:09:00 <zid> https://cdn.discordapp.com/attachments/417023075348119556/913869180858675210/unknown.png k so how do I make qemu smarter than this
19:10:00 <zid> or should I just ask the qemu people
19:11:00 <zid> pf handler should be faulting, breakpoint is on it, instead I get a breakpoint for a fake SIGQUIT
19:11:00 <zid> err pf handler should be *hit* by a fault
19:14:00 <clever> zid: you can tell gdb to ignore signals and let the "signal handler" run as normal
19:15:00 <clever> i often have to do that when debugging linux over jtag with a real arm code
19:15:00 <zid> howhow
19:15:00 <zid> qemu shouldn't be sending a 'signal' though :(
19:16:00 <clever> check the gdb docs for normal signal handling
19:16:00 <clever> and tell gdb to ignore the signal
19:16:00 <zid> that's.. absolutely not what I want though
19:17:00 <zid> qemu has turned the IRQ into a signal, somehow
19:17:00 <zid> I didn't deliver any signals to gdb.. qemu did
19:17:00 <clever> that happens even with real hardware
19:17:00 <clever> openocd turns real irq's on a real arm core into a signal
19:17:00 <clever> and its up to the gdb config to decide if the irq happens normally or gets caught
19:17:00 <zid> so I need to 'pass' on it, so that my *kernel* sees the IRQ?
19:18:00 <clever> yeah
19:18:00 <zid> weird
19:18:00 <zid> let's try pass SIGQUIT
19:19:00 <zid> (gdb) pass SIGQUIT
19:19:00 <zid> (gdb) c
19:19:00 <zid> Program rec..
19:20:00 <zid> nostop it too maybe?
19:21:00 <zid> oh maybe I need *nopass*
19:22:00 <zid> That makes nothing happen
19:26:00 <zid> no matter what I try, I get the signal, I just.. ignore it or not
20:26:00 <zid> I rolled back and I can definitely hit int_pf if I do it from kernel space, but for some reason qemu/gdb *cares deeply* about whether cs&3 = 3?
20:26:00 <zid> yet I can't find anything in the source about sigquit or anything
20:33:00 <zid> at least old builds work, I'll use it to write a decent pf handler and make it stay working as I reapply the new shit
20:34:00 <zid> as I wanted that bp because my pf handler is shitty
20:55:00 <geist> you can also try to debug it without breakpointing with just the -d int stuff
20:55:00 <geist> usually thats enough (in my experience) to see what was going on
20:56:00 <zid> yea I am getting e e 8, with vector 2 on the e
20:56:00 <zid> but I can't get the error code which is the fault addr
20:56:00 <geist> but -d int prints it
20:57:00 <geist> also cr2 is the fault addr of a PF anyway, errcode is the reason (read/write, etc)
20:57:00 <zid> it prints.. v, e, i, cpl, ip, pc, sp, cr2
20:57:00 <zid> ah cr2
20:57:00 <zid> that makes no sense, yay
20:57:00 <geist> that cr2 has the pf address?
20:57:00 <zid> no, -8 makes no sense :P
20:58:00 <geist> ah double fault?
20:58:00 <zid> maybe invalid stack pointer on a failed push to 0?
20:58:00 <geist> sure. the state of the cpu at the 8 is interesting. what does -d int say there?
20:59:00 <geist> possible it's E, E (cant handle this), elevated to 8
20:59:00 <geist> so may mean the state at the time the second E fired is really your problem
21:00:00 <zid> yea the 0x8 doesn't actually print anything
21:00:00 <geist> the 8 what? the output of qemu or your code?
21:00:00 <zid> check_exception old: 0xe new 0x8
21:00:00 <zid> then (qemu)
21:01:00 <zid> rather than the register splat like normal
21:01:00 <geist> i think that makes sense, because the 0xe is the real exception
21:01:00 <geist> a double fault always happens just after a regular one
21:01:00 <geist> so the second 0xe is where things are already bad
21:02:00 <zid> I don't remember it delivering 0xe for 0x8 then a fake 0x8 before, but whatever
21:04:00 <geist> no, the poitn is it *tries* to deliver the second 0xe and then it cant so it elevates it to a 0x8
21:04:00 <geist> that's the definition of a double fault
21:04:00 <zid> right, I don't remember it doing that though
21:04:00 <zid> as in, printing it like this
21:04:00 <geist> but you just said it did a 0xe 0xe 0x8
21:04:00 <geist> so i'm saying go back to the second 0xe and see what the situation was
21:05:00 <zid> same as the first onebut with v=8 instead of v=e, which is.. something the manual will tell me..
21:05:00 <zid> reserved bit set?
21:06:00 <geist> that's whats in the errc?
21:06:00 <zid> oh e is 0, derp
21:06:00 <zid> v is now 8, not e
21:06:00 <geist> okay, i've lost track of whats going on here
21:06:00 <zid> which means it's printing "new fault e" then printing a double fault
21:06:00 <zid> instead of an e
21:07:00 <geist> sound spretty close. also if it happens early enough in boot you can get a full trace if you're really interesting
21:07:00 <geist> `-d exec,cpu,int`
21:07:00 <geist> but that generates a firehouse
21:07:00 <geist> firehose even
21:07:00 <geist> (still haven't finished my coffee)
21:07:00 <zid> nah, I'm not even really interested in the trace, I just wanted debugger control at that point so I could step all the reg saves and stuff
21:07:00 <zid> because I remember the last time I touched this code, having to add rcx to the save list because I forgot before or something and then it was crashing
21:08:00 <zid> and got nerdsniped by gdb not cooperating
21:08:00 <geist> ah can't help you there, i never use source level debuggers
21:08:00 <geist> i'm generally of the opiion that absolutely everything is already there right in front of you
21:08:00 <zid> It's not vital that I get the breakpoint to hit
21:08:00 <geist> and youre so close to figurung it out without fighting the debugger
21:08:00 <zid> I just wanted it as my first action
21:08:00 <zid> >and got nerdsniped by gdb not cooperating
21:08:00 <zid> I could absolutely have just ignored gdb and figured it out :p
21:08:00 <geist> okay
21:09:00 <zid> kinda shitty if my debug environment is hosed though and breakpoints no longer work on kernel functions
21:11:00 <geist> that's why i never assume they're available in the first place
21:12:00 <geist> since by default they are not
21:12:00 <zid> Thankfully they do work, at least in the general case
21:12:00 <zid> just irqs are being funky
21:13:00 <zid> like my pf handler isn't installed or interrupts are masked or something funky
21:13:00 <geist> well i was just about to say honestly the most annoying part is if you want to do all of that absolutely properly you need to get super familiar with the .cfi directives
21:13:00 <geist> and it's a huge mess that makes your asm code a huge mess
21:13:00 <zid> It's actually a C function :P
21:13:00 <geist> we have all of the zircon code cfied up and it really hurts it
21:13:00 <geist> sure but you have asm, and you were just talking about how it may be the stack getting pushed
21:14:00 <geist> side note: you are popping the error code from the first 0xe right? just making sure in case you forgot
21:14:00 <geist> and/or *not* popping the error code on irqs and whatnot right?
21:15:00 <zid> well I always end up back where I should at least
21:15:00 <geist> usually that sort of thing is a straight drop to double faultsville
21:15:00 <zid> if the stack were misaligned by a word cs and ip would get the wrong stuff
21:15:00 <geist> yeah absolutely
21:16:00 <geist> but that didn't really answer the question: did you make sure you're doing it properly on the right irqs?
21:16:00 <geist> exceptions/irqs/etc
21:16:00 <zid> This should be the only thing that ever fires
21:16:00 <zid> and it should be the first fire, and breakpoint the first instruction inside it
21:16:00 <zid> so ultimately, it doesn't matter, I'm not trying to debug the DF
21:17:00 <zid> just why the PF handler either doesn't run, or doesn't get breakpointed
21:17:00 <geist> sure but you said you had plain IRQs as well?
21:17:00 <geist> okay, sounds like we're not on the same page. i will not be nerdsniped by this!
21:17:00 <zid> yea, when I go to actually debug this, I will rip this usercode back down to a while(1);
21:18:00 <zid> and set all its registers to a certain bitpattern
21:18:00 <zid> make sure IRQs still fire (ping the machine)
21:18:00 <zid> and then check none of the registers changed in usermode
21:35:00 <zid> git apply is slow or hanging, not sure which :/
21:41:00 <geist> your poor xeon is struggling
21:41:00 <zid> definitely hung
21:53:00 <klange> well this is an interesting email in my inbox... that I will wait until Monday to even think about replying to...
22:03:00 <sortie> klange only answers boring emails on weekends like a champion
22:03:00 <zid> that sounds like "an email"
22:04:00 <sortie> When I joined $LC_CORP I underestimated how much of my jump would just be like in an office rpg reading exposition infodumps that don't really matter
22:06:00 <klange> The email is from $LC_CORP
22:07:00 <gog> stanley parable
22:07:00 <j`ey> in whose environment are we evaluating $LC_CORP?
22:08:00 <klange> sortie's
22:08:00 <kazinsal> $LC_CORP is evaluated client-side
22:08:00 <sortie> Sometimes $LC_CORP is $LC_SEARCH
22:09:00 <sortie> A very large amount of working at $LC_CORP is $LC_SEARCH'ing how to do my job
22:09:00 <kazinsal> I think that's the case for most computer touchin' jobs
22:10:00 <kazinsal> though I also spend an awful lot of time $LC_SEARCH'ing how to do other peoples jobs for them
22:10:00 <sortie> Recently I'm been getting into interviewing.. actually hired three people so far including one I was leaning no hire on
22:11:00 <kazinsal> so what you're saying is if I need a green card, you're my in
22:11:00 <sortie> Your G&L will be determined accurately and fairly.
22:12:00 <klange> it has been three years since I have had... this experience
22:17:00 <zid> I've now officially messed up my stashes and lost a fix to my irq handler
22:17:00 <zid> and am definitely corrupting the user stack again
22:18:00 <klange> That sounds like Tuesday. You are aware it's Friday/Saturday, right?
22:18:00 <zid> sorry :(
22:19:00 <gog> gotta push rbp on friday
22:19:00 <gog> everybody's lookin for their stack frame
22:24:00 <zid> I had to write it to [gs:8]
23:01:00 <justinfan123> hi, so i've been fighting with xhci on the rpi4 some more, and i get a usb port status change event, but commands on the command ring don't seem to work (never get a response). the controller asserts USBSTS.HSE (and pci status says a target abort occured) but i've got no clue what to do with this information now
23:01:00 <justinfan123> oh oops i forgot to change my nick after messing with twitch's chat :^)
23:03:00 <qookie> anyway, does anyone have any idea how i can actually debug what's wrong?
23:04:00 <zid> that better be a bidoof
23:08:00 <klange> bidoof bidoof bidoof is on fire
23:08:00 <kazinsal> pk0: bidoof on fire
23:26:00 <gorgonical_> geist: what do you mean what class of interrupt? The hypervisor marks the VI bit in hcr_el2 and the Linux driver is supposed to make a hypercall to retrieve the intid. Linux is running at EL1
23:27:00 <gorgonical_> Sorry for the long delay on the follow up lol
23:32:00 <geist> ah was just curious if it was a PPI or SPI or whatnot
23:32:00 <geist> may7be there's different mechanims there?
23:33:00 <gorgonical_> I actually tested yesterday with a different kernel that I know works and it doesn't take the interrupt either. So maybe the qemu version doesn't correctly emulate this?
23:33:00 <geist> no idea. since linux is involved there are so many more variables
23:33:00 <gorgonical_> I've pored over the manual and afaict, if TGE is 0, IMO is 1, and VI is 1, then the Vm should take the interrupt
23:34:00 <gorgonical_> But that's what I mean, since neither linux nor the lwk take the interrupt from the hypervisor
23:34:00 <j`ey> lwk?
23:34:00 <gorgonical_> lightweight kernel
23:34:00 <gorgonical_> We use the Kitten kernel from sandia
23:49:00 <geist> maybe it needs more pets?
23:52:00 <geist> today's silly kvetch: when i suspend my mint linux machine (cinnamon) it always mashes all the windows into the left monitor when i wake it up
23:52:00 <geist> i'm sure there's some phase in restart where only one screen exists so it has to move them over
23:53:00 <kazinsal> multi-monitor has been common for many years now yet no OS seems to be able to consistently get it right
23:53:00 <kazinsal> multi-monitor RDP sessions continue to do weird things
23:54:00 <geist> yah fwiw windows seems to do a pretty good job of remembering window and icon layout for different screen configs. so it may temporarily slam things around but it usually recovers
23:54:00 <geist> i dont think cinnamon even tries, though it doesn't seem to screw with my desktop icons at least
23:54:00 <kazinsal> yeah, my issue seems to usually be if I accidentally bump a cable or something and a monitor "disappears" for a split second
23:55:00 <kazinsal> at least more often than not the one I bump is the one going to the monitor that is my dedicated chat clients monitor so I just have to drag IRC and discord and the like back over
23:55:00 <geist> oh but i discovered a feature of chrome that is a game changer for me: you can name windows
23:55:00 <geist> and, on cinnamon at least, it literally changes the name in the window bar
23:56:00 <geist> you can also do it on windows and mac but since they dont display the name in the bar it isn't as helpful *except* you can find your named window in the menu
23:57:00 <kazinsal> ooh, neat
23:57:00 <geist> i tend to keep 4 or 5 windows of various topics, sometimes spread across a bunch of virtual desktops
23:58:00 <geist> so having a name so i can remember is fantastic
23:58:00 <geist> like programming, osdev, 'main', etc
23:59:00 <j`ey> ive been using tab groups for that
23:59:00 <kazinsal> oh excellent, irccloud has progressive web app support
23:59:00 <geist> yah, my main problem being that tab groups dont move across virtual desktops and if you have more than one profile active it's still nice to see which one is which
23:59:00 <kazinsal> previously I've just been running it in its own browser window fullscreened but that has the side effect of any link I click on being opened in the same window instead of my actual main browser window