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=24&m=4&d=11
00:04:00 <PapaFrog> To recap the earlier advice for me.. One asm file, one C file, right?
00:05:00 <PapaFrog> Maybe just use inline assembly for everything...
00:17:00 <clever> PapaFrog: i generally prefer an asm file over inline asm
00:19:00 <klys_> ye inline asm isn't real asm
00:20:00 <PapaFrog> It was a joke.
00:20:00 <PapaFrog> I think...
00:25:00 <kof673> my will-never-get-there "userland" stuff has strict consistency and allowed tooling/paths/etc., "bootstrap" and someday "kernel" stuff is supposed to have minimal dependencies, so is more free-form
00:26:00 <kof673> and just to be silly i try to 8.3 the latter for now lol
00:26:00 <kof673> the former, absolutely not
00:27:00 <kof673> (but tooling someday may automate some "conversion")
00:27:00 <kof673> i guess that means: whatever your build system works with
00:37:00 <klys_> that may be an argument in favor of a nommu system with a physical allocator, as the dependency would be much less intrusive and allow for such minimalism.
00:40:00 <klys_> really I'm still dreaming of my 16-way buddy system alike allocation algo, and wondering why I added pointers for a linked list
00:45:00 <klys_> then again it comes to mind that resident process 10 -> memory chunk -> memory chunk -> memory chunk; and all three stated chunks belong to process 10.
00:45:00 <kof673> separate object/binary/library/whatever directory, so you can build with different options and "make clean" is just rm -rf obj/ config files top-level or subdir maybe "files user might edit normally, or has to" even wrap defines in conf file inside #ifndef and have a "user conf" file for "overrides" only so they only have to override some things and can pick up defaults normally
00:45:00 <kof673> and then, user normally never edits the main config file, different configurations just need a different "user conf" file
00:47:00 <klys_> I guess what threw me off was that free chunks at varying levels of memory penetration were pointing at each other. I started to imagine that I needed separate free lists, one for each size.
00:48:00 <kof673> i usually have a docs/ for TODO/README and whatever else
00:52:00 <klys_> if you specify 16 buddies of memory for a 32-bit system, you have chunks of the following sizes: 256MB, 16MB, 1MB, 64KB, 4KB
00:55:00 <klys_> for byte granularity within 4KB, a bitmap of 456 bytes (1/9 of 4096) at the end of the page may be used.
00:56:00 <klys_> for mutual exclusion on x86 I just use lock bts and lock btr
03:20:00 * geist yawns
03:20:00 <geist> i had a good day
03:48:00 <gorgonical> attention everyone. I would like to announce that cameras are the work of the devil
03:48:00 <gorgonical> And nobody should willingly agree to program one
03:48:00 <kazinsal> cameras suck. every time one gets pointed at me all the fat on my body seems to migrate to face it
03:49:00 <gorgonical> i cope with this by compulsively running from cameras
03:50:00 <gorgonical> I know you're joking but if this is actually how it worked and you were sufficiently overweight you would be autoanonymous in photographs
03:51:00 <gorgonical> Like ferrofluid attracted to a magnet, you would have your own photoshield
03:52:00 <gorgonical> geist: what happened with pinecone dog
04:15:00 <geist> pinecone dog.... oh the lab
04:15:00 <geist> lab seems to undestatnd 'go home' so she wandered off
08:08:00 <zid> disgusting sky orb time
08:59:00 <gorgonical> embrace your inner deep elf tendencies, acquire an old bunker somewhere, and never again emerge
09:02:00 <zid> It's okay, clouds happened
09:02:00 <mjg> here are some pro tips
09:02:00 <mjg> 1. stop being poor
09:02:00 <mjg> 2. stop being fat
09:02:00 <mjg> that will be 1000USD
09:03:00 <zid> in other news, potato is a much better carb to go with shawarma than rice
09:04:00 <gorgonical> like a shawarma platter but over potatoes
09:04:00 <zid> chips!
09:04:00 <gorgonical> a kapsalon then
09:04:00 <gorgonical> I agree, a better preparation. Was informed it was the local way to eat kebab in amsterdam so I tried it
09:04:00 <zid> I usually have a bit of kebab meat left after I get a kebab cus they're fucking enourmous
09:05:00 <zid> I had some rice I'd already cooked so i'm having it with that, having it with chips is 10x better
09:06:00 <zid> oven chips + kebab + chili sauce + tortilla, very eclectic mix of nationalities going on in that meal :P
09:07:00 <zid> benelux/uk for the chips, anatolia for the kebab meat, north america for the chili sauce, south america for the tortilla, approximately
09:12:00 <kof673> > embrace your inner deep elf tendencies "we must learn the sign language" that phrase works for any situation > Following the zoötypes, the primitive human form of Elder Horus was that of Bes, the dancing dwarf. Bes is a figure of ChildHorus in the likeness of a Negroid Pygmy. He comes capering into Egypt along with the Great Mother, Apt, from Puanta in the far-off south > Final Fantasy IV: The After Years
09:12:00 <kof673> > A dwarf is nothing if he can't jump high
09:12:00 <kof673> somewhere there is a "king" that demands a dwarf dance for him lol
09:34:00 <geist> speaking of bunkers, the new Fallout series may be pretty fun
10:02:00 * gog falls out
10:06:00 <kof673> > And nobody should willingly agree to program one i think i have 2 old parallel port webcams lying around, so at least one of them i think has a linux driver/documentation, should be a simple early "driver" since it needs very little
12:33:00 <gurkenglas> It seems inconvenient that between thinking of a surely-only-several-lines kernel patch and living it lie kernel dev environment setup (the first time), recompilation, and rebooting. Can you recommend me an operating system where I can just edit the code while the system is running?
12:34:00 <mjg> what
12:34:00 <mjg> you do understand you can boot the kernel in a vm
12:35:00 <mjg> fast test cycle is a solved problem
12:36:00 <gurkenglas> sure, that tightens the feedback loop when I need multiple rounds; but the inconvenience I was talking about persists even if we assume it'd work on the first try
12:36:00 <mjg> what inconvenience
12:37:00 <gurkenglas> Firefox has spoiled me with the immediate gratification of responding live to changes in the .css file
12:37:00 <gurkenglas> Some of my current operating system relies on python scripts; that's much better than kernel binaries
12:38:00 <mjg> i'm going to have to refer you to someone else
12:40:00 <gurkenglas> Sure, I imagine I must be sounding entitled and alien in my tastes.
12:43:00 <kof673> nah...just that sounds like JIT-ish "dynamic" story of mel stuff to me :D
12:43:00 <kof673> synthesis os...
12:43:00 <zid> problem with that
12:43:00 <zid> is that if you fuck up something live, you've fucked something up
12:43:00 <kof673> ^^^ or smalltalk or something
12:43:00 <zid> This is more like messing with firefox's rendering engine
12:43:00 <gurkenglas> zid: now *that* sounds like a problem to fix with backups
12:43:00 <zid> not the css
12:43:00 <zid> qemu etc has checkpointing you can use
12:43:00 <mjg> use templeos
12:44:00 <zid> and there is a kernel live-patching tool
12:44:00 <zid> combined you could test some easy changes pretty rapidly
12:44:00 <gurkenglas> zid: nice! thanks. if i end up using this i expect to be running my live system through qemu permanently
12:44:00 <zid> but consider a bug in say, ext4
12:45:00 <zid> The way you ctrl-f5 that is to.. replace the entire drive with a previous image
12:45:00 <mjg> the entire thing looks like a troll question
12:45:00 <zid> or a bug in a driver, and now the hardware is completely unresponsive until it gets power cycled
12:49:00 <gurkenglas> introducing bugs into the drivers that talk to physical hardware that's passed through directly sounds like an acceptable skill issue
12:49:00 <zid> ah yes, the classic "just don't write bugs lol" :p
12:50:00 <gurkenglas> I was thinking "just don't expect this to be a reliable method when you are bypassing the assumptions virtualization is supposed to give you" ^^
12:50:00 <zid> what's the "this"?
12:50:00 <gurkenglas> ability to use eg checkpointing to recover from a bug
12:52:00 <kof673> unity of opposites...dynamicism needs a stable sharp fixed pointy firm edge to bleed upon...
12:54:00 <gurkenglas> (when i say "assumptions virtualization is supposed to give you" I'm thinking "the whole machine is one deterministic program; you can save/load/fork and apply any debugging tools you have", just like with brain uploads in old science fiction.
12:54:00 <gurkenglas> )
12:54:00 <zid> Someone has to write that code, first, if you want it to be true
12:54:00 <zid> and it has to not have bugs too
12:54:00 <zid> checkpointing requires checkpointing code
12:55:00 <zid> To make a *proper* snapshot of a running PC would be *incredibly* difficult, and possibly not even possible in a lot of situations
12:55:00 <zid> because there are externalities like open sockets
12:55:00 <zid> or pending writes to hardware involving DMA
12:55:00 <gurkenglas> i console myself that it's a finite amount of work and then it transfers to all userspace
12:55:00 <zid> the best you can hope for is mostly to throw up a big sign saying 'please settle down', wait for all writes/reads to finish, etc, *then* snapshot
12:55:00 <zid> but even that can just.. never finish
12:55:00 <zid> ever had a zombie process? a hung driver? etc
12:56:00 <zid> And those are exponentially more likely if you're doing active development of course
12:56:00 <zid> So it's a *lot* of effort, and potentially adding lots of bloat to the kernel (which lowers general performance), for questionable gains
12:56:00 <zid> it's something a research kernel might do
12:56:00 <gurkenglas> ...are we still talking about QEMU, or is this now about whether one could get those benefits on the metal too?
12:57:00 <zid> I was responding to <gurkenglas> It seems inconvenient that between thinking of a surely-only-several-lines kernel patch and living it lie kernel dev environment setup (the first time), recompilation, and rebooting. Can you recommend me an operating system where I can just edit the code while the system is running?
12:57:00 <zid> No, and it's hard.
12:57:00 <zid> because kernels need to do unsafe things that may not be recoverable-from
12:58:00 <zid> x86 cpus like to just reboot if you upset them
12:58:00 <zid> good luck undoing that
12:58:00 <gurkenglas> Ah, I was all ready to accept "pick an OS, run it in QEMU" as a family of "operating systems" with ~this feature
12:59:00 <zid> Yea, you should have pretty decent luck with that, but you'll still need something to run inside it
12:59:00 <zid> it won't be foolproof but it'll get you almost all of the way there
12:59:00 <gurkenglas> Are there any reasons not to just wrap whichever system I was using before into QEMU?
13:00:00 <zid> You're just relying on the checkpointing working correctly within qemu
13:00:00 <zid> it may have the exact same issues a real system has
13:00:00 <zid> a pending write completely stalls the checkpoint out
13:00:00 <zid> but you wanted "something you can edit live", so you need to find.. something you can edit live, still
13:00:00 <zid> even if you have checkpointing solved
13:01:00 <gurkenglas> I was foolishly? imagining that QEMU-checkpointing would respond to a pending write by... writing the pending write into the checkpoint
13:01:00 <gurkenglas> and then it'll have to finish after being reloaded
13:01:00 <zid> sounds great if you want massive fs corruption
13:02:00 <immibis> gurkenglas: go and play with squeak smalltalk or whatever may or may not have succeeded it
13:02:00 <zid> buut probably, you can just make the checkpoint *once*
13:02:00 <zid> then apply all your future kernel patches to it at runtime and let it crash and burn etc
13:02:00 <immibis> you can edit the operating system live. It's an untraditional kind of design though
13:02:00 <zid> and not have any issues because the original checkpoint was made successfully
13:02:00 <zid> you'll just struggle to make *more* checkpoints, potentially
13:03:00 <gurkenglas> zid: :confused:. I was imagining the pending write inside the virtual environment; are you saying that QEMU has to wait for the physical hardware to conclude a write that QEMU has initiated?
13:03:00 <zid> my OS talks to the emulated scsi controller
13:03:00 <zid> that scsi controller calls an actual syscall on my host
13:03:00 <zid> to 'emulate' the device
13:04:00 <zid> (by pretending a big file is a real drive, for example)
13:09:00 <gurkenglas> Okay yeah I grant that part of the finite work QEMU needs to do is: when loading a checkpoint, adjust the file handles QEMU has open on the physical disk to match
13:09:00 <zid> loading is the easy part yea, barring things like sockets
13:10:00 <zid> saving it out is a pain because you *almost certainly* want to wait for a quiescent state
13:10:00 <zid> (there may be a --force option or something idk)
13:10:00 <gurkenglas> My armchair expectation would've been that saving is easier because it only involves reads, not writes :x
13:10:00 <gurkenglas> (on the physical side)
13:10:00 <zid> we only care about the qemu side
13:11:00 <zid> and qemu got told to do a write()
13:11:00 <zid> and is now doing one to the host
13:11:00 <zid> it has to wait for that write to finish before it will unblock
13:11:00 <zid> then we told it to checkpoint
13:11:00 <zid> it can now decide either to kill its own threads, or to wait
13:11:00 <zid> not much else it can possibly do
13:11:00 <kof673> old mainframey stuff might have hardware "duplicated" but that is just punting arguably...
13:11:00 <zid> if it kills its own threads, the fs likely ends up corrupt
13:12:00 <kof673> i.e. ok, this hw part mysteriously died, but the spare can continue
13:12:00 <zid> [client program] sys_write -> [client kernel] -> scsi_write() -> [qemu] -> sys_write -> [host kernel] -> scsi-write() -> hardware (afk)
13:12:00 <kof673> in any case, consumer and even most server stuff surely has different "ideology"
13:13:00 <zid> better hope the client program didn't do a 1TB write to a really slow flash stick :D
13:13:00 <gurkenglas> zid, ohh I didn't realize that QEMU can't interrupt host-side writes. then i guess by rights it must not pass through inner writes to the host 1:1 in case those writes eg block forever
13:14:00 <zid> I'm not sure what the impl. chooses to do
13:14:00 <zid> I *doubt* it choses to corrupt the fs, though
13:14:00 <zid> people would notice
13:14:00 <zid> so I imagine it just waits for the writes to the host to finish up
13:17:00 <gurkenglas> If I were to write a QEMU, I imagine the finite amount of code I write would be simulations of about a dozen hardware components in terms of the compute I have which happens to also be on hardware components
13:17:00 <gurkenglas> Regardless of what the simulated hardware hears, I should never put the host in a bad state.
13:17:00 <zid> better let your writes finish then :P
13:21:00 <gurkenglas> yes. My first approach would be to work entirely in RAM ("not enough RAM" sounds like the host's problem, to be addressed with eg more swap space) until I'm to save a checkpoint, which would write that checkpoint to the host's disk.
13:23:00 <gurkenglas> the simulated virus would say "and now write one TRILLION BYTES" and my 'hardware' would say "sure buddy" and the checkpointing code shouldn't notice
13:23:00 <gurkenglas> (shouldn't notice any host-level problems, I mean.)
13:24:00 <zid> well you can do that just fine on qemu, keep the drive small and on a ramfs, and possibly even read only, and you'll never have to care
13:27:00 <gurkenglas> (oops, when I said "entirely in RAM" I should have said "entirely in memory" since RAM refers to the physical volatile memory hardware component and I did mean to include swap)
13:30:00 <gurkenglas> what goes wrong if the drive is not small and not read only? I imagine the simulated RAM should be able to be sized on the order of 75% of the host RAM; would the host start thrashing because it, like, somehow fails to keep the part of QEMU's heap where it keeps the simulated-RAM state in physical-RAM?
13:41:00 <zid> PHYSICAL VOLATILE MEMORY HARDWARE COMPONENT
13:41:00 <zid> is the name of my band
21:36:00 <gorgonical> I've just had a pretty wild idea: would it be possible to counteract global warming by pumping the heat into the earth's core? We can't do this forever, but how much extra surface energy could we pump in?
21:37:00 <gorgonical> I think, for active measures, direct radiation into space is more efficient (?), but the thought of airconditioning the surface by heating the core is funny
21:38:00 <zid> you do know that
21:38:00 <zid> the core is hotter than the surface right
21:38:00 <gorgonical> yeah, but that's also true of regular ac units
21:39:00 <gorgonical> you just have to make the ac unit even hotter than the hotside so it will lose heat to it
21:39:00 <zid> you need a heat exchanger though
21:39:00 <zid> the reason we're not all boiled already is because the heat transfer through rock is shitty
21:40:00 <gorgonical> You would also need some pretty exotic materials and ridiculous temperatures to create the phase change used in regular heat pumps
21:40:00 <zid> (even ignoring the crazy tech)
21:40:00 <gorgonical> To get the refrigerant to the ~1000C or whatever you'd need
21:40:00 <gorgonical> pressures** I meant
21:40:00 <zid> just practically, you could try dump a gigawatt of heat into the deep mantle sure
21:40:00 <zid> but it would just.. stay there
21:41:00 <zid> and you'd have very very very hot rocks touching your heat exchanger
21:41:00 <zid> that would stay hot for a very long time
21:41:00 <gorgonical> Hmm. True. We'd need a huuuuuuge heat exchanger with many locations
21:42:00 <zid> and the deeper you go, to keep the heat 'down' rather than up, the hotter it gets and thus less efficient, and more expensiver
21:42:00 <gorgonical> And to keep the mantle heat in the mantle the device would need to be less conductive
21:42:00 <zid> you'd be better off just lasering it into space or something
21:42:00 <gorgonical> Yeah I think space lasering is definitely better
21:45:00 <zid> the kola superdeep borehole only gets through the crust to the same depth as the mariana trench
21:45:00 <zid> because you know, the pressure down there is like being in the mariana trench :P
21:46:00 <zid> You need to actively cool all the drilling equipment, and it gets upset
21:46:00 <zid> or.. molteny
21:47:00 <zid> 25C per km, it turns out
21:48:00 <gorgonical> The next question is how much energy can you pump into the ground say 10k down before it creates a problem
21:48:00 <zid> so after like 20km all your iron is starting to go soft :P
21:48:00 <zid> I don't think it'd create a problem that we could like.. pin on it
21:48:00 <zid> it would *change* things sure
21:48:00 <gorgonical> Because there are like water collection poles that work by dumping heat to condense water into the ground. But they heat the soil and it stops working after about a week
21:49:00 <zid> but we'd never be able to attribute them
21:49:00 <zid> "This pyroclastic flow moved by 1 milliarcsecond, then 20 thousand years later, this volcano went up here, instead of this one 400m away"
21:51:00 <zid> climate change is an easy fix, anyway, we just run all our systems via capitalism, and it isn't interested
21:51:00 <gorgonical> yeah it's not like black magic to solve. we just don't give a shit lol
21:52:00 <zid> we could start sequestering the tens of billions of tonnes of carbon in huge cubes in a desert somewhere tomorrow
21:52:00 <gorgonical> we're just trying to have our capitalism cake and eat it, too
21:52:00 <zid> or refilling oil wells with carbon slurry or whatever
21:52:00 <zid> we just need to *re* sequestor all of the carbon from all of the oil we extracted
21:56:00 <zid> I like the idea of just painting all of everywhere with calcium nanoparticles
21:57:00 <zid> Paint france.
21:57:00 <gorgonical> An interesting question is what might happen if you did this with a desert
21:57:00 <zid> deserts are pretty white already
21:57:00 <zid> better to do it on all those car parks the US has
21:57:00 <zid> https://i2-prod.dailystar.co.uk/incoming/article15957529.ece/ALTERNATES/s1200c/253060
21:58:00 <zid> France going to look like this when I'm through with it
21:58:00 <gorgonical> I saw an interesting video where artificial opal changes light wavelengths to radiate energy directly, rather than reflecting it
21:59:00 <gorgonical> So if you painted vast swathes of the sahara with this you'd radiatively cool the desert directly into space
21:59:00 <zid> yea but it's already fairly good at that, you wanna do it on something with a lower albedo
21:59:00 <zid> like car parks
21:59:00 <zid> and rooves
21:59:00 <zid> roofs
22:01:00 <zid> albedo of sand is 30%, albedo of water is 10%, albedo of bitumen is 0.05
22:02:00 <gorgonical> Sure, but the thermal emittance is also very important
22:02:00 <zid> caco3 paint can go sub-ambient
22:02:00 <zid> it's *very* good at it
22:02:00 <gorgonical> So can opal paints
22:02:00 <zid> opal is expensive
22:02:00 <zid> this is just limestone
22:02:00 <gorgonical> I guess my point is that we want somewhere with low albedo and high ambient temperature
22:02:00 <gorgonical> But I don't know which is more important to prioritize
22:02:00 <zid> they found the effect using barium oxide or something, then realized calcium oxide works fine too
22:03:00 <zid> you make nanoparticles and it's just really really reflective to white light
22:03:00 <zid> bounces that shit straight back into space
22:03:00 <gorgonical> I thought that the opal nanoparticles also have like 90% thermal emittance, too
22:03:00 <gorgonical> in the "into space" wavelengths
22:03:00 <zid> yes but you *cannot* do this at small scales, or it does nothing
22:04:00 <zid> caco3 is already industrially produced and probably at *least* half as good
22:04:00 <zid> they gave up on barium because barium mining would cost more energy than it saved :P
22:04:00 <gorgonical> but the ideas are exactly the same: reflect sunlight, and turn heat energy into light that will escape through the atmosphere
22:05:00 <gorgonical> opal nanoparticles are probably just too expensive to be worth it at scale
22:05:00 <gorgonical> like the barium
22:05:00 <zid> that was my point, yes
22:05:00 <zid> You want to paint something that's dark, and use paint that can be produced in the billions of litres/yr range
22:06:00 <zid> titanium too expensive, I assume bloody opals are too :p
22:06:00 <gorgonical> I am no industrial chemist so I have no idea whether the opal nanoparticle process scales
22:06:00 <zid> (using price here as a metric for 'how difficult it would be')
22:06:00 <zid> it's not really about how the *process* scales
22:06:00 <zid> it's about how the *material cost* scales
22:06:00 <zid> Lots of things are cheap if you want a global production of 10kg/yr
22:07:00 <zid> but would be absolutely impossible at 1000kg/yr
22:07:00 <zid> and make it cost a billion dollars per gram
22:07:00 <zid> (using cost as a proxy for how many people would need to be employed to do it or whatever in the 'emergency facist world government gulag to save the earth')
22:09:00 <heat> hello
22:09:00 <heat> this gnu hurd thing, are we using it yet
22:09:00 <zid> heat we're banning you from earth
22:09:00 <heat> oh damn
22:09:00 <heat> where am i going
22:10:00 <gorgonical> space
22:10:00 <heat> darn
22:10:00 <heat> oh well
22:10:00 <Mondenkind> i wanna go to space
22:10:00 <zid> or deep in the mantle, we're counting that as 'not on earth' temporarily
22:10:00 <gorgonical> well, really anywhere else but earth
22:11:00 <heat> damn i have many many haters i see
22:11:00 <heat> you know what they say
22:12:00 <heat> if they hate you you're probably doing something right OR you're an insufferable asshole
22:14:00 <heat> this web client is falling over yet
22:14:00 <heat> isn't*. i do wonder if its something about chrome's memory saving or power saving shenanigans that are killing it
22:15:00 <heat> it just loses track of the connection out of nowhere. really weird
22:55:00 <pounce> gorgonical: are you at canonical now
22:55:00 <pounce> what were your SAT scores
22:57:00 <zid> low enough to think about burying hot
22:58:00 <zid> I'm watching someone port .net to windows 95
22:58:00 <zid> so I am clearly stupider though
23:03:00 <mjg> ey heat
23:03:00 <mjg> check out geezers in action actively geezering a utility by adding fsync where it's not warranted
23:03:00 <mjg> https://reviews.freebsd.org/D44742
23:03:00 <bslsk05> reviews.freebsd.org: ⚙ D44742 install: Always use a temporary file.
23:04:00 <mjg> tool has an option to create file in place as is *or* create a temp file, fsync it and rename
23:04:00 <mjg> they are changing the behavior to always use the temp file, whcih does make sense
23:05:00 <mjg> this completely unnecessarily comes with teh fsync though, which they handwave away in the classic geezer fashion
23:05:00 <mjg> quote: Atomicity is well worth the quite minimal potential cost here.
23:05:00 <mjg> down the road when this turns out to shaft performance into oblivion there will be WEBDEVs and other to-be geezers claiming it clearly had to make sense at the time
23:12:00 <gog> zid: mattkc
23:12:00 <gog> i just saw that on my feed
23:12:00 * mjg hugs gog, 2 missisippis
23:13:00 * gog squirm away
23:13:00 <gog> mjg: i've been taking heroic doses of benadryl since last night
23:13:00 <gog> i feel fucken great
23:14:00 <mjg> read some romance novels
23:14:00 <gog> no
23:18:00 <mjg> i had a look at the romance novel subreddit earlier today
23:19:00 <mjg> literal porn addicts in there
23:21:00 <mjg> in 2 meanings