klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
itrsea has quit [Remote host closed the connection]
mrpops2ko has joined #osdev
Matt|home has quit [Quit: Matt|home]
leoh has joined #osdev
leoh has quit [Ping timeout: 276 seconds]
kryptik has quit []
edr has quit [Quit: Leaving]
FreeFull has quit [Ping timeout: 276 seconds]
xtal32k_clk has quit [Quit: WeeChat 4.5.2]
mrpops2ko has quit [Ping timeout: 240 seconds]
c0co has quit [Ping timeout: 276 seconds]
leoh has joined #osdev
<leoh> what are some good os projects to contribute on? as a relative novice to osdev. I have basic training in OS class and have completed MIT's open course 6.828, where I implemented a exokernel os from scratch (of course, with much help from the course material)
Celelibi has quit [Ping timeout: 240 seconds]
Celelibi has joined #osdev
leoh has quit [Ping timeout: 252 seconds]
<geist> i bit my lip
mrpops2ko has joined #osdev
sidcha64 has quit [Quit: The Lounge - https://thelounge.chat]
sidcha64 has joined #osdev
mrpops2ko has quit [Client Quit]
goliath has joined #osdev
leoh has joined #osdev
netbsduser has joined #osdev
leoh has quit [Ping timeout: 260 seconds]
leoh has joined #osdev
netbsduser has quit [Ping timeout: 276 seconds]
Jari-- has quit [Ping timeout: 260 seconds]
leoh has quit [Remote host closed the connection]
leoh has joined #osdev
leoh has quit [Ping timeout: 260 seconds]
dxm is now known as doggo
Gooberpatrol66 has quit [Quit: Konversation terminated!]
Teukka has quit [Read error: Connection reset by peer]
Teukka has joined #osdev
Lucretia has joined #osdev
mahk has quit [Ping timeout: 252 seconds]
doggo has quit []
<Ermine> oh, i915 WARNed
<heat> saddest day of my life
<nikolar> WHAT
GeDaMo has joined #osdev
agent314 has joined #osdev
mzh has quit [Remote host closed the connection]
hanemile has quit [Remote host closed the connection]
zenomat has quit [Remote host closed the connection]
humm has quit [Remote host closed the connection]
uint64_t has quit [Remote host closed the connection]
nagitsu has quit [Remote host closed the connection]
tom5760 has quit [Remote host closed the connection]
rselim has quit [Remote host closed the connection]
lh has quit [Remote host closed the connection]
pitust has quit [Remote host closed the connection]
whereiseveryone has quit [Remote host closed the connection]
baraq has quit [Remote host closed the connection]
asymptotically has quit [Remote host closed the connection]
exec64 has quit [Remote host closed the connection]
sm2n has quit [Remote host closed the connection]
gjn has quit [Remote host closed the connection]
ursa-major has quit [Remote host closed the connection]
tommybomb has quit [Remote host closed the connection]
kyberkiwi has quit [Remote host closed the connection]
lucyy has quit [Remote host closed the connection]
deglebe has quit [Remote host closed the connection]
yuiyukihira has quit [Remote host closed the connection]
mramadany has quit [Remote host closed the connection]
vismie has quit [Remote host closed the connection]
patwid has quit [Remote host closed the connection]
noeontheend has quit [Remote host closed the connection]
ddevault has quit [Remote host closed the connection]
kata has quit [Ping timeout: 240 seconds]
<klys> weird netsplit
<nikolar> ¯\_(ツ)_/¯
vinleod has joined #osdev
vdamewood has quit [Ping timeout: 260 seconds]
Left_Turn has joined #osdev
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 265 seconds]
Turn_Left has quit [Read error: Connection reset by peer]
getz has quit [Quit: metastasizing...]
Left_Turn has joined #osdev
getz has joined #osdev
nagitsu has joined #osdev
whereiseveryone has joined #osdev
baraq has joined #osdev
listentolist has joined #osdev
mzh has joined #osdev
kyberkiwi has joined #osdev
yuiyukihira has joined #osdev
mramadany has joined #osdev
zenomat has joined #osdev
humm has joined #osdev
deglebe has joined #osdev
hanemile has joined #osdev
exec64 has joined #osdev
gjn has joined #osdev
ursa-major has joined #osdev
vismie has joined #osdev
lh has joined #osdev
tom5760 has joined #osdev
uint64_t has joined #osdev
sm2n has joined #osdev
tommybomb has joined #osdev
ddevault has joined #osdev
noeontheend has joined #osdev
asymptotically has joined #osdev
lucyy has joined #osdev
patwid has joined #osdev
pitust has joined #osdev
rselim has joined #osdev
<nikolar> heat: we were talking about fwupdmgr yesterday
<nikolar> and now there's an update kek
kata has joined #osdev
kata has quit [Client Quit]
<heat> kek update or update kek?
kata has joined #osdev
<bslsk05> ​austingroupbugs.net: 0001851: FD_CLOFORK should not be preserved across exec - Austin Group Issue Tracker
<sortie> mjg: Thanks for the information. I can os-test what happens when CLOFORK encounters exec.
<mjg> i already checked everyone clears it
<mjg> i did not look at sortix
<mjg> and i don't know what happens in xnu
<mjg> but the bsds, illumos and solaris all tackle it
<heat> what happens in linux?
<sortie> I would be entirely unsurprised if I do not clear it
<sortie> heat, ETORVALDS
<heat> EVIRO you mean
<sortie> Technically yes but they have the same value as with EAGAIN and EWOULDBLOCK
<mjg> ;)
<nikolar> heat: kek, update kek
<mjg> personally i don't like cloroform either
<bslsk05> ​lore.kernel.org: Making sure you're not a bot!
<heat> viro merely forgot the "Sortix does it, Linux and *BSD do not, thus implement it ASAP"
<mjg> maybe you could respond saying that in fact TODAY the bsds *DO* do it
<mjg> :d
<mjg> i very much dislike hte reasoning for adding it to freebsd
<mjg> as a former de facto maintainer of fd code in freebsd, i can point out some stuff here
<mjg> in other systems you need to store the file pointer and flags like CLOEXEC, ya
<mjg> linux heavily optimizes this for space with dedicated bitmaps
<heat> so does ONYX
<heat> HEAVILY OPTIMIZED ONYX
<mjg> freebsd has "capabilities" on file descriptors, which partially bloats them
<mjg> the thing is, even with "capabilities" in place, there is massive space waste which can be avoided
<heat> is it really a waste if it's being used by CLOFORK?
<mjg> i think you get something like 40 bytes per fd slot
<mjg> afair you could srhink to 24 or so
<mjg> for the common case
<heat> wow that's actually crap lol
<mjg> indeed it is
<mjg> anyway, the said adding cloroform is not a problem cause already bloat
<mjg> which is so backwards
<mjg> ... even if ultimately adding cloform would be the right call
<heat> onyx needs 8 bytes + 2 bits
<mjg> you mean linux
<mjg> :d
<heat> eventually + 1/64 bits once i add a second layer open bitmap
<heat> no, because linux needs the +1/64
<heat> onyx is SIZE OPTIMIZED
<mjg> struct filedescent { struct file *fde_file; /* file structure for open file */ struct filecaps fde_caps; /* per-descriptor rights */ uint8_t fde_flags; /* per-process open file flags */ seqc_t fde_seqc; /* keep file and caps in sync */
<mjg> };
<mjg> oof shit
<bslsk05> ​dpaste.com <no title>
<mjg> there
<heat> for my next trick i'll add both the second layer open and the second layer cloexec
<heat> for RUNTIME OPTIMISED ONYX
<heat> I OPTIMIZE FOR EXECVE
<mjg> i close on open
<mjg> see teh fucken bloat i linked above
<mjg> literally for every fucken fd
<heat> that filecaps stuff could really be a pointer i'd guess
<mjg> you might also notice a literal hole due to int16_t nioctls and uint22_t fcntls
<mjg> you are not going to get away without fc_rights being there, that's mandatory
<mjg> but ioctls (LOL) are rarely present and could be a dedicated fucking struct populated as needed
<heat> is it though?
<heat> how often is capsicum used?
<mjg> few things *set* rights, but everything is looking at them
<heat> if (!fd->fde_caps) /* assume default */
<sortie> clofork is cute and all, but you know what's on my mind? What happens if you call setpgid on a zombie process? Perhaps one that is possibly already a process group leader. What happens if you call tcsetpgrp to a zombie process group?
<mjg> in principle you could indeed have a bit indicating there are any rights
<mjg> sortie: lol process group stuff is giving me flashbacks
<heat> struct fileascent { struct file *fd_file; struct filecaps *fde_caps; /*... */ }
<mjg> apart from being terrible in its own right, it also happens to be buggy AF on the old unix systems
<mjg> heat: mofer you literally just spent 8 bytes on a pointer
<sortie> mjg, these questions are like super important it turns out when it comes to race conditions in the shell when spawning pipelines
<mjg> largely defeating the point
<heat> ideally you'd get rid of fde_seqc, and then fde_flags could probably also be collapsed into fd_file's low bits
<heat> mjg: how?
<sortie> Fun fact, without spoiling the results, the actual behavior between systems vary
<mjg> sortie: it always does ;)
<mjg> heat: now that you mention this shit you gave me an idea
<mjg> struct file is turbo aligned
<mjg> 64 or something
<mjg> maybe you could in fact WHACK the cloexec bitmap
<mjg> and just mask it off when reading the pointer?
<sortie> gcc -whack
<heat> mjg: you would need to prove the masking off of bits doesn't regress but yeah, sounds acceptable
<heat> cromulent if i may
<mjg> well yes, it is to be evaluated
<mjg> oh heh
<mjg> if this works
<mjg> linux could also accept cloroform
<mjg> :d
<mjg> as it would not add overhead
<heat> NAK NAK NAK NAK NAK
<mjg> i'm gonna do it
<mjg> whack the cloexec bitmap
<heat> not just the masking off of bits, but also the execution of the actual closes
<mjg> and after it gets merged try to sneak in cloform
<mjg> !!
<mjg> sortie: re process groups, this was part of the code in the bsds which never actually freed their target
<mjg> sortie: so de facto UAF bugs when unnoticed
<sortie> eep
<mjg> or rather, would not crash the kernel. at worst you would get weird violations of expected behavior
<mjg> but even that would require looking really close to run into it
<mjg> since we are talking about the area, i'm curious what are you doing for ptrace
EmanueleDavalli has joined #osdev
<mjg> specifically, do you reparent the tracee to the tracer?
<heat> sortix no ptrace
<sortie> I have no ptrace at the moment so that part is trivial
<mjg> ;)
<mjg> smart choice
<sortie> It's been a little while (decade) since I looked into ptrace so my memory is super fuzzy
<sortie> But I'd generally prefer for my debugging interfaces to not reparent stuff
vdamewood has joined #osdev
<mjg> hue
<mjg> there is a harmless race in linux vs cloexec
<mjg> no locks are held when issuing F_SETFD
<mjg> so you can find there is a file installed under the fd, but the nproceed to set the bit as the file disappear
<mjg> s
<mjg> however, installing a file always clears or sets the bit
<mjg> this leaves you with the following race where userspace can fuck with itself:
vinleod has quit [Ping timeout: 248 seconds]
edr has joined #osdev
<mjg> A: F_SETFD finds the file
<mjg> B: closes the file
<mjg> C: opens a file, it lands on the same fd
<mjg> A: sets cloexec on it
<heat> yes there are?
<bslsk05> ​elixir.bootlin.com: Making sure you're not a bot!
<mjg> the lock is held around the actual modification of the bitmap
<mjg> not the decision to do it
<mjg> see above for the description of the race
<mjg> race-free would hold some lock from fd -> file translation all the way to setting/clearing teh bit
<heat> ah yes
<heat> it also silently supposes the fd table doesn't shrink
<mjg> well it is an implicitly provided invariant
<mjg> i mean i agree the assumption is not stated
<mjg> but it is already depended on for lockless fd lookup
<mjg> so
<heat> not necessarily
<heat> yeah __fget_files_rcu does not assume that
<mjg> oh the count is tied to the size
Left_Turn has quit [Remote host closed the connection]
Left_Turn has joined #osdev
Left_Turn has quit [Read error: Connection reset by peer]
Left_Turn has joined #osdev
Left_Turn has quit [Read error: Connection reset by peer]
Left_Turn has joined #osdev
EmanueleDavalli has quit [Quit: Client closed]
Left_Turn has quit [Read error: Connection reset by peer]
Left_Turn has joined #osdev
Left_Turn has quit [Read error: Connection reset by peer]
Left_Turn has joined #osdev
<heat> sortie: re setpgid on ded processes, i remove the process from the pgid+session when _reaped_
<zid> why are you aping things twice
<sortie> heat: That's the Linux behavior too, and I think it's better.
agent314 has quit [Ping timeout: 276 seconds]
<sortie> There is a shell race condition where it's building a whole pipeline, making one process a process group leader, and then making each other process, and putting them into the process group. BUT the process group leader might, depending on scheduling, exit faster than the rest of the pipeline can be built
<sortie> To do things properly and race condition free, one traditionally runs setpgid in both the child and the parent shell process, when making the process group leader. That way you know it's definitely in the process group. But that setpgid call in the parent shell might actually be run on a zombie process, since it may have exited, but hasn't been waited for yet
<sortie> However, many systems, including BSD (will publish data momentarily), may fail to setpgid on a zombie child because it doesn't exist any more
<sortie> In those cases, setgid may give you ESRCH and you're a bit fucked when constructing the rest of the pipeline
Left_Turn has quit [Read error: Connection reset by peer]
Left_Turn has joined #osdev
<mjg> is that a *real* problem or a hypothetical
<mjg> as in, is the race window big enoguh that you can realistically run itno it?
<sortie> I've definitely had cases like it happen on Sortix
<sortie> true | less # cheap left hand sides like that, with some worst case scheduling outcomes
<sortie> It's also complicated by foreground process groups, where you also need to tcsetpgrp to the new foreground process group (and what happens if it's a zombie)
<sortie> I think we've all learned by now that even extremely unlikely race conditions do occur, right?
<sortie> https://sortix.org/os-test/#process ← Here is the data for setpgid on zombie process groups (and a control test)
<bslsk05> ​sortix.org: os-test
<heat> EINVAL and EPERM is definitely weird
<sortie> https://sortix.org/os-test/#pty ← Data for tcsetpgrp on zombie process groups. Curiously, everyone allows tcsetpgrp to a zombie process group, even when they don't allow setpgid on it
<bslsk05> ​sortix.org: os-test
<sortie> heat: EINVAL is minix being minix (broken and abandoned), EPERM is Sortix being stricter than it has to be (which is what caused me my bugs, and why I investigated everyone's behavior, since POSIX doesn't mention this case directly)
<mjg> :O
<mjg> where did you get aix3
<sortie> mjg, I've been known to locate systems, from time to time
<sortie> mjg, hehehe I've been granted access to cfarm, the gcc compile farm
<heat> these days it's harder to avoid aix than to get it
<heat> it's everywhere!
<sortie> something something boys brings aix to the yard
<sortie> It is seriously useful, though, to ponder how different systems implement weird edge cases, and then write a couple quick tests, and get data from *everywhere*. Don't forget y'all can just send an easy os-test MR if you got anything you wanna test like that and I'll happily get you the data
<mjg> fucking corner cases
<mjg> bane of existence
<sortie> They're fun :D
<heat> why would you do that with corner cases? that's kind of weird
<sortie> Legit I can pick any system call, send absurd inputs to it, and I will highly likely find a bug in *some* Unix
<mjg> well
<mjg> we are maybe 1 decade off of literally CRASHING systems by trivially fuzzing system calls
<heat> trinity bro!
<mjg> and by trivially fuzzing i mean picking args at random
<heat> syzkaller probably also has decently wide support for whatever systems you're testing
<mjg> and yes, that includes the bsds and SOLARIS
<sortie> I am actually surprised I haven't crashed any kernels yet
<sortie> I guess my inputs aren't that cursed
<mjg> are the kernels running with debug?
<mjg> if not, i think yo uare just 1 decade too late
<sortie> My inputs are usually implementation defined, if not standardized
<mjg> i refer you to my previous remarks about not-freed objs
<mjg> around process group management in the bsds
<sortie> Yeah that bug was embarrassing
<mjg> here is a funny story
<sortie> I did spent a lot of work in early Sortix development making sure processes did not leak
<mjg> netbsd added a bunch of asserts in the area
<mjg> i figured that sounds good, i added them in freebsd and smoke tested the system
<mjg> all good
<mjg> ... except it started crashing after i committed
<mjg> ended up reverting :D
<mjg> they did eventually get
<sortie> My biggest defense against memory leaks in Sortix is the overnight 12-hour 3 million process system self-build. If anything starts leaking, it's probably going to explode with an OOM
<heat> spotify asks me to reload the web page every 2-3 days
<heat> for a "better experience"
<heat> i assume this is a memleak
<sortie> but whose
<mjg> would be funny if they only recommended the reload on your browser, would not it
<mjg> lol at the 4th to last test case on https://sortix.org/os-test/#process
<mjg> trio-send-wrong-y-connect-send-right-x-recv
<mjg> are you sure you got it right
<mjg> being literally the only os which operates differently
<sortie> mjg: It's legit a mild security issue in everyone else
<sortie> mjg: There's a race condition where between socket() and connect(), an UDP socket can receive a datagram from a wrong other remote address, and it gets delivered even though connect() on UDP will only receive datagrams from the specified address
<sortie> It's one of those race conditions that are so short, and requires the attacker to somehow know the correct port and exact timing, and involve a program that somehow connects UDP socket, and where a bad datagram can have a bad impact (and isn't properly checked), so... nobody else considered it a security issue
<nikolar> sortie: what do you do with cfarm
<mjg> sortie: huh
<sortie> nikolar: I run https://sortix.org/os-test/ on their proprietary unixes (the machines I can't get virtual machines of)
<bslsk05> ​sortix.org: os-test
<nikolar> cute
<sortie> It's really one of my strongest tools to make Sortix interoperable in depth and to find bugs in all unix systems :)
<heat> sortie: i think i saw a CVE in linux semi-recently where the problem was that they were *not* delivered
<heat> :)
goliath has quit [Quit: SIGSEGV]
<mjg> yo heat
<heat> sup
<mjg> what's the aftermath of that musl vs string ops fiasco
<mjg> did anything change
<heat> of course
<heat> not
<mjg> D
EmanueleDavalli has joined #osdev
<heat> ping me again in 2045 once compilers figure out OPTIMAL vectorization
<GeDaMo> Does APL count? :P
<heat> can you send this to musl? thanks
<mjg> i thought he is your friend
<heat> who?
<mjg> dalias
<mjg> anyway this code is shite
<heat> loller
<mjg> you don't want the one byte loop
<heat> idk mofer gemini thinks it's OPTIMAL
<heat> so it is
<mjg> my bad then
kata has quit [Read error: Connection reset by peer]
<mjg> LOL
kata has joined #osdev
<mjg> terribad
<mjg> > musl's memcpy implementation is generally considered fast, especially for its design goals of being lightweight, simple, and standards-compliant, but it might not always be the absolute fastest compared to highly specialized glibc implementations on certain high-end server CPUs.
<mjg> :(
<heat> we're growing optimal-er by the minute
<heat> i'm positively surprised with it in this case
<mjg> ask if it would be faster if it was in RUST
<heat> i switched to pro and i'm almost getting it to understand overlapping loads/stores
<heat> it just needs a small eastern european village's yearly water supply for each prompt
<heat> i suppose dalias hasn't examined this way of doing string ops
<heat> overlapping doesn't mean what it thinks it means, but we're approaching perfection
<heat> at this point just deploy it to prod and we'll iron out the kinks
<mjg> this is all stale tho
<mjg> i do zerocopy memcpy
<mjg> but i'm not gonna share how
<heat> kernel-assisted memcpy with page remapping tricks
<heat> the gang uses vmsplice
<mjg> bro
<mjg> check out a pipe hack in freebsd
<mjg> it probably made sense back when it was implemented
<mjg> i verified that now it mostly wastes time
<mjg> after the SMPification and related overhead
<mjg> write can literally block the caller and wire the pages to avoid doing a copy
<mjg> into the kernel
<mjg> the problem is that now this comes with a shitload of atomics to stabilize the state (and then undo it)
<heat> uvm also does that
<mjg> even with this issue aside, it is unclear if mandatory blocking here is any good
<mjg> in principle the caller could be spending that time getting ready to produce more data
<heat> block the caller how?
<heat> that seems weird honestly
<mjg> it literally stops executing
<heat> in any case in THE LINUX KERNEL you can explicitly opt into doing that sort of stuff with vmsplice, splice and tee
<heat> and sendpages
<mjg> fwiw the freebsd pipes are pretty chopped
<heat> and THE GNU OPERATING SYSTEM is optimized towards that
<mjg> but i'm not going to go into details
<heat> pipes in general aren't the greatest thing in the world to implement
<heat> but you know that
<mjg> are you baiting me to point out the real shit which does not have to be there or what
<heat> no
<mjg> i'm gonna share some shit anyway since you insist
<mjg> so there is a part of KVA carved out for pipe buffers
<heat> i literally said no
<heat> :(
<mjg> and pipes are allowed to go both ways. to that end you get 2 separate allocations
<mjg> and ofc freeing that trigger a TLB flush
<mjg> meaning pipe-heavy shit results in an idiotic IPI traffic
tjf has quit [Ping timeout: 252 seconds]
randm has quit [Ping timeout: 252 seconds]
randm has joined #osdev
* Ermine writes pessimal stuff at $dayjob
Gooberpatrol66 has joined #osdev
<Ermine> copying stuff to userspace and back to a device
<Ermine> utter crapper
<Ermine> unsolvable without a kernel though
<Ermine> kernel driver*
kata has quit [Read error: Connection reset by peer]
kata has joined #osdev
leoh has joined #osdev
mahk has joined #osdev
EmanueleDavalli has quit [Quit: Client closed]
EmanueleDavalli has joined #osdev
EmanueleDavalli has quit [Quit: Client closed]
vdamewood has quit [Quit: Life beckons]
<geist> PESSIMAL
<heat> do you use gemini to write fuchsia code?
wgrant has quit [Ping timeout: 252 seconds]
wgrant has joined #osdev
pabs3 has quit [Ping timeout: 245 seconds]
* klys bid on the decmate ii
pabs3 has joined #osdev
leoh has quit [Ping timeout: 240 seconds]
<klys> and won
<nortti> nice. what'cha gonna do with it?
leoh has joined #osdev
<klys> try and hook it up to a breadboard or see if it boots through the serial port, also first dump the chargen rom for mame, and then more of that. I don't have the rx01/rx02 board for it, so I may need to get that somehow in the future.
<klys> I do however have two rx02 drives here
<klys> am meaning to reproduce drawings for said drives
<klys> presently wondering about the drive motor, as it has five wires, may have to determine the pinout by hooking it up or something
netbsduser has joined #osdev
jcea has joined #osdev
Matt|home has joined #osdev
teejay has quit [Ping timeout: 260 seconds]
karenw has joined #osdev
Left_Turn has quit [Remote host closed the connection]
wgrant has quit [Ping timeout: 248 seconds]
Left_Turn has joined #osdev
wgrant has joined #osdev
<ZetItUp> i tried to use chatgpt to help with programming, it gets so bad after a while and starts going in circles :/
leoh has quit [Ping timeout: 244 seconds]
<ZetItUp> working on a little bootloader and it crashed everytime just before going into protected mode, and chat gpt kept going on and on about IDT table was not set, cause i pasted a QEMU register log to it, so it got super stuck on that every problem was IDT related after that
<zid> kek
<heat> i don't know man i got gemini to give me a pretty good optimized memcpy
<zid> anything stealable it can do fine
<heat> it might work it might not, i don't know, i don't care, lets test it in prod
<zid> because it stole it already
<zid> it's basically the xkcd for coding by just gluing stackoverflow results together
<ZetItUp> yeah i noticed that aswell, alot of code it gave was some variant of one type of code
<zid> well, it's an LLM
<zid> that's literally how they work and what they're for
<zid> you pirate 40 novels on dragons into it and it can sort of make a random mashup of shit novels about dragons
<ZetItUp> also i gave it my full boot.asm file, it seems to forget after a while because, all of a sudden when i asked for stuff, it gave me weird code, so i asked where it found it, and it said "You have it in your code right here" and gave me a code snippet, nothing in that code was any of my code :D
<bslsk05> ​gkoberger.github.io: stacksort
<zid> Found it
<ZetItUp> wth :D
<kof673> > [LLMs] generate natural language, or human-like text they are assuming written is "natural" instead of picture writing :D
<kof673> that is not to say better or worse, just they are carrying out one giant conway's law :D
zid has quit [Ping timeout: 252 seconds]
zid has joined #osdev
<zid> ipv6 is illegal to own and operate today apparently
GeDaMo has quit [Quit: 0wt 0f v0w3ls.]
<heat> as it should
c0co has joined #osdev
zid has quit [Remote host closed the connection]
zid has joined #osdev
leoh has joined #osdev
EmanueleDavalli has joined #osdev
karenw has quit [Ping timeout: 248 seconds]
EmanueleDavalli has quit [Quit: Client closed]
<Ellenor> rawr
jcea has quit [Ping timeout: 272 seconds]
Turn_Left has joined #osdev
Left_Turn has quit [Ping timeout: 252 seconds]
leoh has quit [Ping timeout: 248 seconds]
zid has quit [Ping timeout: 248 seconds]
izabera is now known as isabella
alice has quit [Ping timeout: 244 seconds]
Left_Turn has joined #osdev
Turn_Left has quit [Ping timeout: 260 seconds]
vdamewood has joined #osdev
Left_Turn has quit [Read error: Connection reset by peer]
hydrocarboxide has joined #osdev
Lucretia has quit [Remote host closed the connection]
leoh has joined #osdev
<heat> nikolar: Ermine: every time I suspend the system I get a WARN_ON from amdgpu
<heat> i'm not even using the gpu!
<nikolar> nice
<heat> the real high quality linux graphics driver was the friends we made along the way
<heat> at least nvidia suspend seems to be working...ish now?
itrsea has joined #osdev
<nikolar> "ish"
<nikolar> sounds about right
<Ellenor> ish. (-:
<Ellenor> it's a neat suffix