foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
gamozo has quit [Quit: Lost terminal]
bradd has joined #osdev
_whitelogger has joined #osdev
Beato has joined #osdev
phr3ak has quit [*.net *.split]
edr has quit [*.net *.split]
mats1 has quit [*.net *.split]
gaze___ has quit [*.net *.split]
relipse has quit [*.net *.split]
kaichiuchi has quit [*.net *.split]
ggherdov has quit [*.net *.split]
stephe has quit [*.net *.split]
hl has quit [*.net *.split]
stephe has joined #osdev
ggherdov has joined #osdev
kaichiuchi has joined #osdev
gaze___ has joined #osdev
<geist>
Huh TIL that `hexdump` has a whole formatting mechanism where youcan give it printf style output string
mats1 has joined #osdev
<geist>
It’s pretty nice
relipse has joined #osdev
hl has joined #osdev
<zid`>
I knew it had a bunch of options, not sure I knew about the printf one
phr3ak has joined #osdev
edr has joined #osdev
dmh has quit [*.net *.split]
seds has quit [*.net *.split]
geist has quit [*.net *.split]
dennisschagt has quit [*.net *.split]
MrBonkers has quit [*.net *.split]
HeTo has quit [*.net *.split]
seds has joined #osdev
dennisschagt has joined #osdev
dmh has joined #osdev
MrBonkers has joined #osdev
geist has joined #osdev
<geist>
Yeah. (Dunno why I got bumped there)
HeTo has joined #osdev
<zid`>
because you were on the wrong server
<zid`>
wallops have been going out to tell you to change because they're starting em
<zid`>
re
liz has quit [Quit: Lost terminal]
Fox has joined #osdev
kazinsal_ has joined #osdev
les_ has joined #osdev
<geist>
Ah i see. Well I’m coming in via irccloud so i can’t decide what server it connects to
<geist>
Just had to take the bump and let it reconn
<kazinsal_>
yeah, same
ornitorrincos_ has joined #osdev
kazinsal has quit [Killed (NickServ (GHOST command used by kazinsal_))]
ebb_ has joined #osdev
kazinsal_ is now known as kazinsal
<geist>
random thing i think I’m going to settle in for the night: write a 6800 emulator for an Altair680
<geist>
Why? I dunno, but i already have al title emulator project and it’s easy to add another cpu to it, and the 6800 is like a one-evening project
gdd1 has joined #osdev
j`ey_ has joined #osdev
eau_ has joined #osdev
sbalmos1 has joined #osdev
klys_ has joined #osdev
<zid`>
I was thinking of rewriting mine but I haven't worked up the gumption
gdd has quit [Ping timeout: 272 seconds]
j`ey has quit [Ping timeout: 272 seconds]
sbalmos has quit [Ping timeout: 272 seconds]
eau has quit [Ping timeout: 272 seconds]
LittleFox has quit [Ping timeout: 272 seconds]
ebb has quit [Ping timeout: 272 seconds]
ornitorrincos has quit [Ping timeout: 272 seconds]
klys has quit [Ping timeout: 272 seconds]
les has quit [Ping timeout: 272 seconds]
Mutabah has quit [Ping timeout: 272 seconds]
LambdaComplex has quit [Ping timeout: 272 seconds]
GreaseMonkey has quit [Ping timeout: 272 seconds]
ebb_ is now known as ebb
Mutabah_ has joined #osdev
Mutabah_ is now known as Mutabah
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
srjek has quit [Ping timeout: 255 seconds]
Vercas has quit [Remote host closed the connection]
FatAlbert has joined #osdev
<kazinsal>
gah. why does pidgin still not have a dark mode on windows in 2022
Vercas has joined #osdev
klys_ is now known as klys
vdamewood has joined #osdev
Likorn has joined #osdev
opal has quit [Ping timeout: 240 seconds]
zaquest has quit [Remote host closed the connection]
opal has joined #osdev
the_lanetly_052 has joined #osdev
bauen1 has quit [Ping timeout: 256 seconds]
Vercas5 has joined #osdev
Vercas has quit [Ping timeout: 240 seconds]
Vercas5 is now known as Vercas
wand has quit [Remote host closed the connection]
Vercas has quit [Remote host closed the connection]
Vercas has joined #osdev
<FatAlbert>
why do you use windows in 2022
<FatAlbert>
?
<mrvn>
because if I remove the windows and it rains then my monitor gets wet.
<mrvn>
*duck*
<vdamewood>
mrvn: It's a fair enough answer to such a question.
Vercas has quit [*.net *.split]
foudfou has quit [*.net *.split]
opal has quit [*.net *.split]
gxt has quit [*.net *.split]
opal has joined #osdev
gxt has joined #osdev
Vercas has joined #osdev
foudfou has joined #osdev
bauen1 has joined #osdev
<FatAlbert>
how much time it take before WW3?
<FatAlbert>
i think 2 years from now, hell gonna break loose
<FatAlbert>
i want it because it will be egood for my interests
<klange>
I don't think that's appropriate topic of discussion for this channel, unless you think the spark is going to be over operating system choices.
<FatAlbert>
when ~80% of a nation is dead there will be what i call social reset
<FatAlbert>
i just hope i won't be part of these 80%
* vdamewood
pots away his troll food.
<vdamewood>
puts*
<FatAlbert>
everyone will have a chacne to start all over
<FatAlbert>
also after a war ... all bad blood has been cleared
<FatAlbert>
it's a new life !
<vdamewood>
I think I want to fit my entire kernel in the lower 640k of memory.
<FatAlbert>
in essence we are getting close to the new 60s or 70s ... isn't that beautiful ?
<clever>
vdamewood: some of my kernel builds run on just 128kb of L2 cache, and not even touching ram
<mrvn>
FatAlbert: unless it's an AI uprising I have <20% confidence of your survival.
<FatAlbert>
wow so little faith ...
Likorn has quit [Quit: WeeChat 3.4.1]
<klange>
what if it _is_ an AI uprising?
<FatAlbert>
most of people who have been thorough half of what i have in life are either committed suicide in jail or are on drugs somewhere
<mrvn>
The AI might keep him around for some menial programming work. Or target nerds with a vengance so they don't write a virtus to take it down. Uncertain.
<mrvn>
-t
<FatAlbert>
also
<FatAlbert>
i have the power of invisibility ... what do you think i won't survive ?
<FatAlbert>
why
<vdamewood>
mrvn: Maybe an "I have no mouth, and I must scream" scenario.
<mrvn>
FatAlbert: you will be run over by an automated truck on the first day.
<FatAlbert>
i see the light at the end of the tunnel ...
<FatAlbert>
it's a beautiful time .. and i have no intention of not be there
<psykose>
>60s
<psykose>
>good
<psykose>
epic bait
<FatAlbert>
i sometimes wonder, how death will eventually find me
<FatAlbert>
a survivor like me.
<FatAlbert>
are you guys also wonder it ?
<kazinsal>
I more often wonder what exactly it is about this hobby that attracts the weirdest people
<FatAlbert>
by wierdest people you mean me, ok, but what hobby are we talking about ?
<FatAlbert>
anyway
<FatAlbert>
i just hope ill pass on these genes. someone down the road might make better use of it
gog has joined #osdev
pretty_dumm_guy has joined #osdev
foudfou has quit [Remote host closed the connection]
<bslsk05>
gcc.gnu.org: Function Specific Option Pragmas (Using the GNU Compiler Collection (GCC))
<heat>
I was thinking of those
<heat>
but i dunno if it works with fbuiltin
<Arsen>
"Each function that is defined after this point is treated as if it had been declared with one optimize(string) attribute for each string argument." time to see what optimize is
<Arsen>
hah that's it, you're a genius!
<Arsen>
thanks heat
<klange>
any -f option, without the -f
<heat>
thank you arsen, I know
<heat>
my intellect knows no bounds
<Arsen>
nor does your modesty :^)
<heat>
my phd thesis will be based on random GCC tidbits and facts
opal has quit [Remote host closed the connection]
<heat>
:P
opal has joined #osdev
<klange>
(though the -fno-builtin* stuff isn't listed in the "options that control optimization" section, so whether or not that actually works is... unknown, have fun!)
<Andrew>
zid`: the register points to a memory locaation eight-bytes long (64-bit) that points to a disk location to store the weather
<heat>
we're doing pmem?
<Arsen>
oh true, hmm
<Arsen>
well, time for a test I suppose
<Arsen>
alternatively, I'll just build these files into a static lib without builtins and link that
<heat>
IT DOES NOT WORK
<heat>
MY INTELLECT DOES KNOW BOUNDS
<heat>
I HAVE DISHONORED MY FAMILY
<j`ey>
clever: having trouble with -serial pty. I run qemu with that, and then 'picocom /dev/pts/8', but I dont see any output, any ideas?
heat has quit [Read error: Connection reset by peer]
<Arsen>
klange: indeed, builtin is not permitted there
<Arsen>
unfortunate
heat has joined #osdev
opal has quit [Remote host closed the connection]
opal has joined #osdev
<heat>
j`ey, just tried with screen and it works here
<heat>
I get a /dev/modem: No such file or directory with minicom
<j`ey>
screen doesnt get me any output either
<heat>
well, you're not getting any old output
<j`ey>
ok screen does work actually
<heat>
praise be gnu and gnu/linux, or as I've recently taken to call it, GNU plus Linux
Raito_Bezarius has quit [Ping timeout: 255 seconds]
liz_ has joined #osdev
mahmutov has joined #osdev
Raito_Bezarius has joined #osdev
dude12312414 has quit [Remote host closed the connection]
dude12312414 has joined #osdev
\Test_User has joined #osdev
LambdaComplex has joined #osdev
dennis95 has joined #osdev
<FatAlbert>
she got a smile that it seems to em
<FatAlbert>
heat: it turns out to be that vscodevim also includes easyomtion which is the vim plugin i wanted for vscode :)
<sbalmos>
heat was trying cooperative channel chatter. should've just preempted. ;) everyone gets a channel quantum to sa... *interrupted*
* geist
yawns
<geist>
good afternoon folks!
* mjg_
yawns back
* mjg_
codes something for fan for the first time in weeks
<mjg_>
fun even
<mjg_>
upside of slack: i could have edited the above
FatAlbert has quit [Ping timeout: 248 seconds]
dude12312414 has quit [Ping timeout: 268 seconds]
dude12312414 has joined #osdev
dude12312414 has quit [Remote host closed the connection]
<geist>
oh cool
Dreg has quit [Ping timeout: 240 seconds]
Dreg has joined #osdev
X-Scale` has joined #osdev
\Test_User has quit [Ping timeout: 240 seconds]
mahmutov has quit [Ping timeout: 240 seconds]
sympt9 has joined #osdev
pretty_dumm_guy has quit [Ping timeout: 240 seconds]
sympt has quit [Ping timeout: 240 seconds]
GeDaMo has quit [Ping timeout: 240 seconds]
liz_ has quit [Ping timeout: 240 seconds]
sympt9 is now known as sympt
dennis95_ has joined #osdev
bauen1 has quit [Ping timeout: 268 seconds]
zaquest has quit [Ping timeout: 268 seconds]
mavhq has quit [Ping timeout: 264 seconds]
X-Scale has quit [Ping timeout: 264 seconds]
LambdaComplex has quit [Ping timeout: 240 seconds]
dennis95 has quit [Ping timeout: 240 seconds]
X-Scale` is now known as X-Scale
\Test_User has joined #osdev
mahmutov has joined #osdev
bauen1 has joined #osdev
pretty_dumm_guy has joined #osdev
liz has joined #osdev
<sbalmos>
*yawn* is it Friday yet?
<psykose>
yeah
<sbalmos>
if (!time::current_day()->day_of_week == time::DayOfWeek::Friday) { reality::current_mental_state->block(); }
zaquest has joined #osdev
GeDaMo has joined #osdev
LambdaComplex has joined #osdev
mavhq has joined #osdev
<heat>
SIGCONT
<heat>
What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.
<sbalmos>
heat: SIGCONT handler is a while-not-Friday loop :P
wand has joined #osdev
Matt|home has quit [Ping timeout: 248 seconds]
<geist>
reading the xtensa arch manual, it's fairly interesting bt nothing to write home about
<geist>
the register window is kinda funny, so it has an odd ABI thats definitely strange
<geist>
though not so much to people that are used to register windows at least
<sbalmos>
never heard of it. another neat little core?
<heat>
i think xtensa is pretty old lol
<geist>
sort of. it's a synthesizable core from Cadence. Mostly aware of it because it is in ESP32, though ESP32 is moving towards riscv
<geist>
but doug16k was fiddling wit it the other day so got me to looking up the arch manual
<sbalmos>
ah, yeah okay I remember it being mentioned now
<geist>
16 registers, can rotate by 4 8 or 12 on call entry (that's the call4/call8/call12) so there's some interesting arg passing and return going on there
<geist>
ie, in that case it puts args in a10/11/12 and uses a call8, which rotates the registers down by 8, so the incoming args are in a2/3/4
<geist>
a0/a1 are always the return address + stack pointer, which gets copied in the entry basically, so yo uget a fresh copy of the return address and stack
GeDaMo has quit [Quit: There is as yet insufficient data for a meaningful answer.]
<geist>
the N of how far the register window was rotated is orred into the saved PC in a0 (top 2 bits it seems)
<geist>
that's how the ret instruction knows how much register window to uncover
<geist>
(16 registers, so a0-a15)
<sbalmos>
oh fun
<geist>
anyway, just a little mystery i wanted to solve. it's not that interesting, but i like different cpu architectures just cause
<sbalmos>
in the meantime, I've been shamefully hanging my head over the weekend and today, trying to concretely remind myself exactly how a thread blocks, waits, is woken up, etc. Obviously know the theory. Just down to concrete impl stuff. Took far too long to really boil it down to thread.state = State::Blocked; scheduler::switch();
<sbalmos>
catching up on a hobby you wanted to get into 20 years ago, right out of college, is hell.
<geist>
usually my strategy is the state is mostly contined in whether or not the thread is 'discoverable' by the scheduler or not
<geist>
ie, the thread structure is in one list most of the time (or running)
<sbalmos>
ya
<geist>
if it's in the scheduler list it's ready to run, if it's sitting on a wait queue, it's blocked
<geist>
if it's running it's 'owned' by the cpu
<geist>
only time it may be in no list at all is when it's sleeping, or suspended, but theres other tracking data to get it back i nto the run queue
<sbalmos>
it was more fundamental than that. The whole idea of a blocking read basically boiling down to a driver literally yielding, like cooperative multitasking
<geist>
in that sort of design the state enum on the thread is moslty there so you can quickly determine what to do with it when you run an operation against it
<geist>
well, i think with a wait queue style design the whole idea of a blocking read is the driver provides/has a primitive to put the current thread on until some point in the future that the driver wakes it up
<sbalmos>
right
<geist>
so the thread just appears blocked on something, but the something is the driver's responsibility
<sbalmos>
gets into mutexes and poll-waiters, etc. but from the fundamental perspective, it gets into the mutex now being the point that literally calls yield
<bslsk05>
github.com: lk/virtio-block.c at master · littlekernel/lk · GitHub
<sbalmos>
otherwise a "blocking read" by a driver could be stupidly implemented by an idiot driver writer and actually busy-wait rather than actually really blocking
<bslsk05>
github.com: lk/virtio-block.c at master · littlekernel/lk · GitHub
<sbalmos>
ya
<sbalmos>
it's funny how much I remember from college, conceptually, but it's reading it in code that clicks
<geist>
it's a very simple driver since it doesn't allow queing. the blocking thread is holding a mutex across the operation which keeps only one thread in there
<geist>
yah figured that might help
<geist>
if it was more of a queued/multi io thing then the driver needs to build up some notion of pending transactions, and probably put a wait queue (event_t) in each of those, so the individual thread can wait on an individual transaction
<sbalmos>
at the very least I was reading Redox source and already tilting my head at some stuff they do in there, either seemed left-over or really... not right
<geist>
and then the irq handler would have to disambiguate which transaction the irq is completing and wake up the appropriate thread, etc
<sbalmos>
yup
<geist>
yah i glanced a bit at the redox stuff. i'm mostly chalking it up to not knowing rust that well, but i kinda get the impression it's written by folks that haven't done a lot of osdev
<geist>
but i may just be not grokking rust
<sbalmos>
nah it's not that. I don't know much rust either. But I tend to pick up on new languages, etc /very/ quickly once I actively start using them. And even then I've quickly gotten the sense of a lot of their code organization, you get that instinctual feeling things aren't right
<geist>
rust may tend to force you down a particularly unoptimal path for this sort of thing, though
<geist>
it always seems like the ownership model would work against you for a lot of these core 'toss this on a list and get to it from some other context' style stuff that tends to be in the deep of kernels
<sbalmos>
dunno yet, honestly
<heat>
sbalmos, usually the busy-wait drivers are the best ones ;)
<sbalmos>
heh
<heat>
as in, actively tuned and feature complete
<sbalmos>
WTF did my CPU jet engine just take off? I was just trying to read a file!
<heat>
intel mac moment
<heat>
I introduce to you: RWF_HIPRI (man 2 preadv2)
<sbalmos>
geist: took me a long while to find the entrypoint from gigaboot was actually top/main.cc . Kept looking in all kinds of other places.
<heat>
kernel block device polling!
<geist>
ah well, entry to the kernel you mean?
<sbalmos>
YUP
<sbalmos>
gah, sorry
<geist>
it's not entirely true, the entry is actually in arch/<arch>/start.S
<geist>
it then eventually calls kmain()
<sbalmos>
well yeah, I was there first
<geist>
top/main.cc is basically just the first part of the C code
<sbalmos>
right, just on my neverending quest to trace-read the process
<sbalmos>
bad enough CLion doesn't set up header search paths without a CMakeLists file, so I can't ctrl-click the header file includes :D
<heat>
doesnt it use compile_commands.json?
<geist>
sbalmos: you'll also note that the structure is basically the same as LK, that part hasn't really changed much
<geist>
you'll see a lot of shared DNA there
<sbalmos>
ya
<sbalmos>
heat: /supposedly/ it should. but I have yet to get the project to recognize it on opening.
<sbalmos>
hang on. this might be a difference in how IDEA/CLion, a few vers back, changed their open structure. It didn't recognize if I opened from the fuchsia dir, but is now asking if I want to treat the file as a project if I tried to open compile_commands.json directly
<geist>
yah the compile_commands works pretty good, tough it's the whole shebang, including non kernel stuff
<geist>
i have also been running a ctags over the whole thing which mostly works, though there are some kernel headers and whatout outside of the kernel dir
<sbalmos>
I think I'm going to have to blow away all the previously generated .idea dirs. It's still not recognizing any headers
<geist>
heads up: i think there's some deconstruction of the zircon dir that's about to happen, so stuff will move around soon
<geist>
the incessant need to move things around in the source repo is a constant among the project, but i think it'll end up getting move to src/zircon/kernel or something, but some of the other bits in zircon/ are going elsewhere
FatAlbert has joined #osdev
gildasio has quit [Quit: WeeChat 3.5]
<sbalmos>
<Bones> "I know engineers, they love to change things..."
<heat>
jeez, again? :/
<heat>
clangd works fine but for a lot of files it needs some arguments to not blow up your machine
<sbalmos>
good thing I don't really need my home desktop here for another 20 minutes while it chews through the indexing. ;)
<sbalmos>
bah, stupid WSL
<psykose>
heat: what arguments? :)
<heat>
--background-indexing=false?
<heat>
--background-index even
<heat>
so, --background-index=false
<psykose>
thanks!
<heat>
although after re-reading clangd docs this doesn't seem that great of an idea
<heat>
i usually just take the hit upfront
<sbalmos>
ooof, stupid lack of symlink following in \\wsl$ paths
GreaseMonkey has joined #osdev
Likorn has joined #osdev
dennis95_ has quit [Quit: Leaving]
<liz>
feeling very silly... spent a lot of time prodding my machine code to diagnose a PIC issue, only to realise i forgot to add an sti instruction in protected mode
mahmutov has quit [Ping timeout: 276 seconds]
<geist>
oh eep
<geist>
yeah that'll do it
<geist>
though that's better than the other, having sti enabled when you're not ready for it. that's harder to debug
<sbalmos>
geist: unsurprisingly I'm finding reading lk a lot more straightforward than zircon. probably just a sheer size thing.
<geist>
yeah the zircon stuff has gotten much larger, though the structure is somewhat the same
<sbalmos>
it is, more or less. so lk doesn't have any IPC stuff by what I can tell, right?
<clever>
j`ey: not sure, ive not used it here
<j`ey>
clever: got it working in the end, was an oopsie on my side
<geist>
not too much, it does have a central 'port' mechanism, but the general idea is that only if it's really really cross-functionally useful does it get promoted to 'core' primitive
<geist>
whereas various sub projects have built their own mechanisms for what they do
<geist>
general overall idea being that LK is simplicity first
<sbalmos>
yup, saw the port, and that's what I figured thinking it further
<geist>
pretty much all of the core code is not fundamentally ipc based. more of a traditional blocking primitives and from that one builds queues/etc
<sbalmos>
zircon probably builds the idea of a channel and everything else on top of a port and some mutexes, etc if it's to block. easily compose a message "mailbox" on top of that
<sbalmos>
yup
<clever>
j`ey: what was it?
<geist>
precisely. port i dont think survived, but for the msot part mutex/event/wait queue/semaphores are still there, just converted to C++ and beefed up a bit
<sbalmos>
oh hell it's almost 6:30 already. haven't even thought of dinner.
<geist>
and all the higher level zircon code is built on top of it. LK is very much still there as the core to the whole thing, it's just been converted to C++
<geist>
and certain scaling decisions have been made that involve rebuilding some things
<geist>
(ie, the scheduler)
<sbalmos>
well it's basically the same as how Darwin is really Mach at the original core, etc
<geist>
yah, and over time they diverge but the DNA is still there
<j`ey>
clever: I was printing a small amount of characters before hanging. I had a 'sleep 1 ; screen /dev/pts/N' loop in another terminal.. and the printing was so quick it had already always output stuff during the time it was sleeping
<clever>
j`ey: ah, ive seen basically the same problem with MCU's emulating a usb tty
<clever>
i think if you use -S to start qemu, it will create the tty, but halt the cpu
<clever>
then you can resume it at a time of your choosing
<j`ey>
clever: via the monitor I suppose?
<clever>
yeah
<sbalmos>
geist: funny (not really) how this is easier to wade through than Minix or others, when you kinda know what you're looking for and know what it's supposed to look like on paper, but not fully in code.
<clever>
the monitor should also let you query what tty the serial landed on
<clever>
and you can rig the monitor into a unix socket if you want to automate it all
<geist>
sbalmos: that's been generally my strategy. i need to write many more docs for LK, but i'm so bad a it
<geist>
zircon, i'd hope it's still easy, but frankly the code we're writing is not really designed to be easy to read, somewhat to my chagrin
<geist>
i try, but it's a non-goal of the project, alas
<sbalmos>
yeah :/
<sbalmos>
it's turned from research/academic keep-it-studyable to commercial
<j`ey>
thats why LK must live :D
<geist>
yah, it's sort of the inevitability of it, alas
<geist>
i *do* encourage folks to write docs for LK if your'e bored. there's a wiki next to it
<geist>
and i haven't figured out precisely what i want to do re:wiki vs .md files, but all else held equal probably starting with the wiki is not a bad idea
<geist>
can at least flatten some of that out
<sbalmos>
I mean the Fuchsia dev docs do a great job on their own. But not so much from a "here's how things map in the directory structure / function-name level" past the syscall function names
<bslsk05>
github.com: nixpkgs/machine.py at master · NixOS/nixpkgs · GitHub
<clever>
j`ey: this will run qemu with -monitor unix:/path/to/socket
<geist>
sbalmos: yeah agreed. and worse we keep rearranging things. for better or worse google has no fear constantly reformatting/refactoring/moving. i think that's part of the DNA of the company
<sbalmos>
and it's taken me a while to learn to properly spell Fuchsia. :P
<sbalmos>
ayup
<geist>
incessantly redo things. i think it does actually work in the long run, but it doesn't make it easy to find thins
<j`ey>
clever: cool, maybe unix socket is better than guessing the pts will be N because I have N-1 terminals open :P
<geist>
i fought it for a whiel, but really it's just The Way.
<geist>
also git makes it at least a lot easier to deal with than older SCMs
<sbalmos>
geist: there's constantly stuff in FIDL I still can't find where it's defined
<clever>
j`ey: one sec
<geist>
you should see the internal mailing lists that are constantly 'X is being replaced by Y'
<sbalmos>
heh
<geist>
oh oops, i just let my machine OOM building clang
<geist>
wasn't paying attention while typing here :)
<geist>
64GB and just blew through 32GB of swap in a few seconds
<j`ey>
JOB_POOL_LINK, use it!
<geist>
and now it's totally frozen. j`ey oh? how does one?
<sbalmos>
heheheheh
<geist>
-DJOB...?
<j`ey>
yeah
<geist>
will give it a go when i get back. gotta run to the store
<bslsk05>
'Silicon Photonics: The Next Silicon Revolution?' by Asianometry (00:15:45)
gog has quit [Ping timeout: 255 seconds]
* geist
mentions Everything Everywhere all at Once again. Fantastic movie
<j`ey>
weird and fantastic
<mjg_>
hm
<geist>
I watched a bunch of making of, and am also pleasantly surprised to see it was pretty cheap to make and they were very scrappy with mostly practical effects
<geist>
Sort of an anti-Marvell movie in terms of sci if and action
<mjg_>
:))
<mjg_>
in that case adding to my watchlsit
<j`ey>
but still multiverse :p
<mjg_>
which part of "everything everywhere all at once" you missed
<mjg_>
:>
<geist>
But still multiverse yeah. The creators said they were a little bummed that multiverse stuff got popular recently, because they’ve been basically working on it for like 10 years, but so it goes
<geist>
OTOH maybe it primes audiences a bit to deal with the multiverse stuff in general.
<klys>
one of a select few movies i did see
<geist>
Yah i think it was the first one I’ve seen in a theater since the start of the pandemic
<zid`>
lmk when it's on iptorrents
<moon-child>
iptorrents? Isn't that a really trashy torrent tracker?
<zid`>
not trashy in the least
<geist>
Honestly this is such a good movie and indie enough that they deserve your money
<zid`>
I don't have any money
<geist>
Fine, but just sayin.
<zid`>
all I can do is watch it then recommend to others to buy it
<zid`>
or not, depending :p
<zid`>
like, all my friends have seen primer because I wouldn't shut up about it
<geist>
Indeed, thats one i didn’t shut up about either for a few years
<geist>
Now that I’ve forgotten enough of it i should watch it again
<zid`>
TIL qemu supports memory mapped shm between host and guest
<zid`>
-object memory-backed-file,size=size
<geist>
Yup. You can also file back the entire physical address space that way
<geist>
One way to pre-fill it with random data
<geist>
And if you use a COW file system or whatnot you can easily track deltas
<zid`>
I should use -memory-backend or whatever to make that my vga memory
<zid`>
and make my host machine repaint the background image as a gif or something
<geist>
I have no idea what the performance impact of actually backing it to disk would be though, seems like Linux would be fairly furiously writing it back to try to get modified state to zero
<geist>
But backing it to tmpfs or whatnot would be a way to get basically anonymous memorybacking it, but be able to examine the contents post-facto or whatnot
liz has quit [Ping timeout: 276 seconds]
<geist>
I thought i had read that some VM hosting solutions did that for some benefit