LittleFox has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
LittleFox has joined #osdev
<PapaFrog>
To recap the earlier advice for me.. One asm file, one C file, right?
<PapaFrog>
Maybe just use inline assembly for everything...
<clever>
PapaFrog: i generally prefer an asm file over inline asm
<klys_>
ye inline asm isn't real asm
<PapaFrog>
It was a joke.
<PapaFrog>
I think...
xvmt has quit [Read error: Connection reset by peer]
hunta987 has quit [Quit: Lost terminal]
<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
xvmt has joined #osdev
<kof673>
and just to be silly i try to 8.3 the latter for now lol
<kof673>
the former, absolutely not
<kof673>
(but tooling someday may automate some "conversion")
netbsduser has quit [Ping timeout: 252 seconds]
<kof673>
i guess that means: whatever your build system works with
edr has quit [Quit: Leaving]
<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.
<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
k0valski18891621 has quit [Ping timeout: 268 seconds]
<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.
<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
<kof673>
and then, user normally never edits the main config file, different configurations just need a different "user conf" file
<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.
<kof673>
i usually have a docs/ for TODO/README and whatever else
thegrinchmann has joined #osdev
<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
<klys_>
for byte granularity within 4KB, a bitmap of 456 bytes (1/9 of 4096) at the end of the page may be used.
<klys_>
for mutual exclusion on x86 I just use lock bts and lock btr
troseman has joined #osdev
troseman has quit [Client Quit]
netbsduser has joined #osdev
tjf has quit [Ping timeout: 264 seconds]
j00ru has quit [Ping timeout: 260 seconds]
tjf has joined #osdev
netbsduser has quit [Ping timeout: 268 seconds]
j00ru has joined #osdev
j00ru has quit [Ping timeout: 260 seconds]
thegrinchmann has quit [Ping timeout: 256 seconds]
j00ru has joined #osdev
Fingel has joined #osdev
netbsduser has joined #osdev
netbsduser has quit [Ping timeout: 268 seconds]
* geist
yawns
<geist>
i had a good day
netbsduser has joined #osdev
<gorgonical>
attention everyone. I would like to announce that cameras are the work of the devil
<gorgonical>
And nobody should willingly agree to program one
<kazinsal>
cameras suck. every time one gets pointed at me all the fat on my body seems to migrate to face it
<gorgonical>
i cope with this by compulsively running from cameras
<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
<gorgonical>
Like ferrofluid attracted to a magnet, you would have your own photoshield
<gorgonical>
geist: what happened with pinecone dog
Fingel has quit [Ping timeout: 272 seconds]
gbowne1 has quit [Remote host closed the connection]
gbowne1 has joined #osdev
netbsduser has quit [Ping timeout: 252 seconds]
<geist>
pinecone dog.... oh the lab
<geist>
lab seems to undestatnd 'go home' so she wandered off
rustyy has quit [Quit: leaving]
rustyy has joined #osdev
netbsduser has joined #osdev
netbsduser has quit [Ping timeout: 252 seconds]
zetef has joined #osdev
zetef has quit [Client Quit]
zetef has joined #osdev
netbsduser has joined #osdev
netbsduser has quit [Ping timeout: 260 seconds]
zetef has quit [Ping timeout: 256 seconds]
carbonfiber has joined #osdev
netbsduser has joined #osdev
stolen has joined #osdev
zetef has joined #osdev
Brnocrist has quit [Ping timeout: 272 seconds]
netbsduser has quit [Ping timeout: 252 seconds]
gbowne1 has quit [Quit: Leaving]
<zid>
disgusting sky orb time
netbsduser has joined #osdev
spare has joined #osdev
GeDaMo has joined #osdev
netbsduser has quit [Ping timeout: 264 seconds]
netbsduser has joined #osdev
<gorgonical>
embrace your inner deep elf tendencies, acquire an old bunker somewhere, and never again emerge
<zid>
It's okay, clouds happened
<mjg>
here are some pro tips
<mjg>
1. stop being poor
<mjg>
2. stop being fat
<mjg>
that will be 1000USD
<zid>
in other news, potato is a much better carb to go with shawarma than rice
netbsduser has quit [Ping timeout: 260 seconds]
<gorgonical>
like a shawarma platter but over potatoes
<zid>
chips!
<gorgonical>
a kapsalon then
<gorgonical>
I agree, a better preparation. Was informed it was the local way to eat kebab in amsterdam so I tried it
<zid>
I usually have a bit of kebab meat left after I get a kebab cus they're fucking enourmous
<zid>
I had some rice I'd already cooked so i'm having it with that, having it with chips is 10x better
<zid>
oven chips + kebab + chili sauce + tortilla, very eclectic mix of nationalities going on in that meal :P
<zid>
benelux/uk for the chips, anatolia for the kebab meat, north america for the chili sauce, south america for the tortilla, approximately
Nixkernal has quit [Read error: Connection reset by peer]
Nixkernal has joined #osdev
<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
<kof673>
> A dwarf is nothing if he can't jump high
<kof673>
somewhere there is a "king" that demands a dwarf dance for him lol
gog has joined #osdev
<geist>
speaking of bunkers, the new Fallout series may be pretty fun
carbonfiber has quit [Quit: Connection closed for inactivity]
bauen1 has quit [Ping timeout: 268 seconds]
* gog
falls out
<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
bitoff has joined #osdev
Left_Turn has joined #osdev
netbsduser has joined #osdev
stolen has quit [Quit: Connection closed for inactivity]
zxrom has quit [Quit: Leaving]
zetef has quit [Ping timeout: 255 seconds]
navi has joined #osdev
staceee has quit [Read error: Connection reset by peer]
xtex has quit [Remote host closed the connection]
alethkit has quit [Read error: Connection reset by peer]
ursa-major has quit [Read error: Connection reset by peer]
rselim has quit [Read error: Connection reset by peer]
yuiyukihira has quit [Read error: Connection reset by peer]
tom5760 has quit [Read error: Connection reset by peer]
asymptotically has quit [Remote host closed the connection]
jtbx has quit [Read error: Connection reset by peer]
sm2n has quit [Read error: Connection reset by peer]
lh has quit [Read error: Connection reset by peer]
patwid has quit [Read error: Connection reset by peer]
pitust has quit [Remote host closed the connection]
jleightcap has quit [Remote host closed the connection]
noeontheend has quit [Remote host closed the connection]
exec64 has quit [Remote host closed the connection]
whereiseveryone has quit [Remote host closed the connection]
listentolist has quit [Remote host closed the connection]
hanemile has quit [Remote host closed the connection]
tommybomb has quit [Read error: Connection reset by peer]
vismie has quit [Remote host closed the connection]
gjn has quit [Write error: Connection reset by peer]
patwid has joined #osdev
staceee has joined #osdev
hanemile has joined #osdev
tom5760 has joined #osdev
listentolist has joined #osdev
pitust has joined #osdev
rselim has joined #osdev
jtbx has joined #osdev
xtex has joined #osdev
gjn has joined #osdev
ursa-major has joined #osdev
jleightcap has joined #osdev
yuiyukihira has joined #osdev
whereiseveryone has joined #osdev
vismie has joined #osdev
noeontheend has joined #osdev
exec64 has joined #osdev
tommybomb has joined #osdev
alethkit has joined #osdev
asymptotically has joined #osdev
lh has joined #osdev
sm2n has joined #osdev
lh has quit [Remote host closed the connection]
jtbx has quit [Remote host closed the connection]
hanemile has quit [Remote host closed the connection]
patwid has quit [Remote host closed the connection]
ursa-major has quit [Remote host closed the connection]
jleightcap has quit [Remote host closed the connection]
listentolist has quit [Remote host closed the connection]
yuiyukihira has quit [Remote host closed the connection]
vismie has quit [Remote host closed the connection]
gjn has quit [Read error: Connection reset by peer]
tom5760 has quit [Remote host closed the connection]
whereiseveryone has quit [Read error: Connection reset by peer]
tommybomb has quit [Remote host closed the connection]
rselim has quit [Remote host closed the connection]
sm2n has quit [Remote host closed the connection]
staceee has quit [Remote host closed the connection]
pitust has quit [Remote host closed the connection]
xtex has quit [Remote host closed the connection]
alethkit has quit [Remote host closed the connection]
exec64 has quit [Remote host closed the connection]
noeontheend has quit [Remote host closed the connection]
asymptotically has quit [Remote host closed the connection]
listentolist has joined #osdev
staceee has joined #osdev
patwid has joined #osdev
gjn has joined #osdev
hanemile has joined #osdev
pitust has joined #osdev
whereiseveryone has joined #osdev
vismie has joined #osdev
ursa-major has joined #osdev
noeontheend has joined #osdev
tommybomb has joined #osdev
asymptotically has joined #osdev
tom5760 has joined #osdev
sm2n has joined #osdev
alethkit has joined #osdev
exec64 has joined #osdev
jtbx has joined #osdev
rselim has joined #osdev
jleightcap has joined #osdev
xtex has joined #osdev
yuiyukihira has joined #osdev
netbsduser has quit [Ping timeout: 256 seconds]
MiningMarsh has quit [Ping timeout: 252 seconds]
MiningMarsh has joined #osdev
darkstardevx has joined #osdev
darkstardevx has quit [Remote host closed the connection]
chiselfuse has quit [Ping timeout: 260 seconds]
chiselfuse has joined #osdev
zxrom has joined #osdev
MiningMarsh has quit [Ping timeout: 268 seconds]
edr has joined #osdev
MiningMarsh has joined #osdev
spare has quit [Remote host closed the connection]
bauen1 has joined #osdev
gurkenglas has joined #osdev
<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?
<mjg>
what
<mjg>
you do understand you can boot the kernel in a vm
<mjg>
fast test cycle is a solved problem
<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
<mjg>
what inconvenience
<gurkenglas>
Firefox has spoiled me with the immediate gratification of responding live to changes in the .css file
<gurkenglas>
Some of my current operating system relies on python scripts; that's much better than kernel binaries
<mjg>
i'm going to have to refer you to someone else
<gurkenglas>
Sure, I imagine I must be sounding entitled and alien in my tastes.
<kof673>
nah...just that sounds like JIT-ish "dynamic" story of mel stuff to me :D
<kof673>
synthesis os...
<zid>
problem with that
<zid>
is that if you fuck up something live, you've fucked something up
<kof673>
^^^ or smalltalk or something
<zid>
This is more like messing with firefox's rendering engine
<gurkenglas>
zid: now *that* sounds like a problem to fix with backups
<zid>
not the css
<zid>
qemu etc has checkpointing you can use
<mjg>
use templeos
<zid>
and there is a kernel live-patching tool
<zid>
combined you could test some easy changes pretty rapidly
<gurkenglas>
zid: nice! thanks. if i end up using this i expect to be running my live system through qemu permanently
<zid>
but consider a bug in say, ext4
<zid>
The way you ctrl-f5 that is to.. replace the entire drive with a previous image
<mjg>
the entire thing looks like a troll question
<zid>
or a bug in a driver, and now the hardware is completely unresponsive until it gets power cycled
<gurkenglas>
introducing bugs into the drivers that talk to physical hardware that's passed through directly sounds like an acceptable skill issue
<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" ^^
<zid>
what's the "this"?
<gurkenglas>
ability to use eg checkpointing to recover from a bug
<kof673>
unity of opposites...dynamicism needs a stable sharp fixed pointy firm edge to bleed upon...
<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.
<gurkenglas>
)
<zid>
Someone has to write that code, first, if you want it to be true
<zid>
and it has to not have bugs too
<zid>
checkpointing requires checkpointing code
<zid>
To make a *proper* snapshot of a running PC would be *incredibly* difficult, and possibly not even possible in a lot of situations
<zid>
because there are externalities like open sockets
<zid>
or pending writes to hardware involving DMA
<gurkenglas>
i console myself that it's a finite amount of work and then it transfers to all userspace
<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
<zid>
but even that can just.. never finish
<zid>
ever had a zombie process? a hung driver? etc
<zid>
And those are exponentially more likely if you're doing active development of course
<zid>
So it's a *lot* of effort, and potentially adding lots of bloat to the kernel (which lowers general performance), for questionable gains
<zid>
it's something a research kernel might do
<gurkenglas>
...are we still talking about QEMU, or is this now about whether one could get those benefits on the metal too?
<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?
<zid>
No, and it's hard.
<zid>
because kernels need to do unsafe things that may not be recoverable-from
<zid>
x86 cpus like to just reboot if you upset them
<zid>
good luck undoing that
<gurkenglas>
Ah, I was all ready to accept "pick an OS, run it in QEMU" as a family of "operating systems" with ~this feature
<zid>
Yea, you should have pretty decent luck with that, but you'll still need something to run inside it
<zid>
it won't be foolproof but it'll get you almost all of the way there
<gurkenglas>
Are there any reasons not to just wrap whichever system I was using before into QEMU?
<zid>
You're just relying on the checkpointing working correctly within qemu
<zid>
it may have the exact same issues a real system has
<zid>
a pending write completely stalls the checkpoint out
bauen1 has quit [Ping timeout: 255 seconds]
<zid>
but you wanted "something you can edit live", so you need to find.. something you can edit live, still
<zid>
even if you have checkpointing solved
<gurkenglas>
I was foolishly? imagining that QEMU-checkpointing would respond to a pending write by... writing the pending write into the checkpoint
<gurkenglas>
and then it'll have to finish after being reloaded
<zid>
sounds great if you want massive fs corruption
<immibis>
gurkenglas: go and play with squeak smalltalk or whatever may or may not have succeeded it
<zid>
buut probably, you can just make the checkpoint *once*
<zid>
then apply all your future kernel patches to it at runtime and let it crash and burn etc
<immibis>
you can edit the operating system live. It's an untraditional kind of design though
<zid>
and not have any issues because the original checkpoint was made successfully
<zid>
you'll just struggle to make *more* checkpoints, potentially
<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?
<zid>
my OS talks to the emulated scsi controller
<zid>
that scsi controller calls an actual syscall on my host
<zid>
to 'emulate' the device
<zid>
(by pretending a big file is a real drive, for example)
Turn_Left has joined #osdev
<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
Left_Turn has quit [Ping timeout: 255 seconds]
<zid>
loading is the easy part yea, barring things like sockets
<zid>
saving it out is a pain because you *almost certainly* want to wait for a quiescent state
<zid>
(there may be a --force option or something idk)
<gurkenglas>
My armchair expectation would've been that saving is easier because it only involves reads, not writes :x
<gurkenglas>
(on the physical side)
<zid>
we only care about the qemu side
<zid>
and qemu got told to do a write()
<zid>
and is now doing one to the host
<zid>
it has to wait for that write to finish before it will unblock
<zid>
then we told it to checkpoint
<zid>
it can now decide either to kill its own threads, or to wait
<zid>
not much else it can possibly do
<kof673>
old mainframey stuff might have hardware "duplicated" but that is just punting arguably...
<zid>
if it kills its own threads, the fs likely ends up corrupt
<kof673>
i.e. ok, this hw part mysteriously died, but the spare can continue
<kof673>
in any case, consumer and even most server stuff surely has different "ideology"
<zid>
better hope the client program didn't do a 1TB write to a really slow flash stick :D
<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
<zid>
I'm not sure what the impl. chooses to do
<zid>
I *doubt* it choses to corrupt the fs, though
<zid>
people would notice
<zid>
so I imagine it just waits for the writes to the host to finish up
<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
<gurkenglas>
Regardless of what the simulated hardware hears, I should never put the host in a bad state.
<zid>
better let your writes finish then :P
<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.
<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
<gurkenglas>
(shouldn't notice any host-level problems, I mean.)
<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
<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)
<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?
<zid>
PHYSICAL VOLATILE MEMORY HARDWARE COMPONENT
<zid>
is the name of my band
goliath has joined #osdev
Brnocrist has joined #osdev
zetef has joined #osdev
gurkenglas has quit [Read error: Connection reset by peer]
Maja has quit [Quit: No Ping reply in 180 seconds.]
Maja has joined #osdev
cross has quit [Remote host closed the connection]
Fingel has joined #osdev
zetef has quit [Remote host closed the connection]
xenos1984 has quit [Ping timeout: 260 seconds]
xenos1984 has joined #osdev
Fingel has quit [Quit: Fingel]
Fingel has joined #osdev
gog has quit [Quit: Konversation terminated!]
bauen1 has joined #osdev
stolen has joined #osdev
theyneversleep has joined #osdev
bitoff has quit [Ping timeout: 272 seconds]
Matt|home has joined #osdev
Fingel has quit [Quit: Fingel]
carbonfiber has joined #osdev
xenos1984 has quit [Ping timeout: 272 seconds]
Fingel has joined #osdev
gog has joined #osdev
Brnocrist has quit [Ping timeout: 264 seconds]
Brnocrist has joined #osdev
xenos1984 has joined #osdev
Cindy has quit [Ping timeout: 272 seconds]
Cindy has joined #osdev
netbsduser has joined #osdev
Fingel has quit [Remote host closed the connection]
Cindy has quit [Ping timeout: 252 seconds]
linear_cannon has quit [Read error: Connection reset by peer]
linear_cannon has joined #osdev
Cindy has joined #osdev
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
stolen has quit [Quit: Connection closed for inactivity]
Cindy has quit [Ping timeout: 255 seconds]
Cindy has joined #osdev
linearcannon has joined #osdev
linear_cannon has quit [Ping timeout: 260 seconds]
vdamewood has joined #osdev
gog has quit [Ping timeout: 255 seconds]
<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?
<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
<zid>
you do know that
<zid>
the core is hotter than the surface right
<gorgonical>
yeah, but that's also true of regular ac units
<gorgonical>
you just have to make the ac unit even hotter than the hotside so it will lose heat to it
<zid>
you need a heat exchanger though
<zid>
the reason we're not all boiled already is because the heat transfer through rock is shitty
gbowne1 has joined #osdev
<gorgonical>
You would also need some pretty exotic materials and ridiculous temperatures to create the phase change used in regular heat pumps
<zid>
(even ignoring the crazy tech)
<gorgonical>
To get the refrigerant to the ~1000C or whatever you'd need
<gorgonical>
pressures** I meant
<zid>
just practically, you could try dump a gigawatt of heat into the deep mantle sure
<zid>
but it would just.. stay there
<zid>
and you'd have very very very hot rocks touching your heat exchanger
gbowne1 has quit [Remote host closed the connection]
<zid>
that would stay hot for a very long time
<gorgonical>
Hmm. True. We'd need a huuuuuuge heat exchanger with many locations
gbowne1 has joined #osdev
<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
<gorgonical>
And to keep the mantle heat in the mantle the device would need to be less conductive
<zid>
you'd be better off just lasering it into space or something
<gorgonical>
Yeah I think space lasering is definitely better
<zid>
the kola superdeep borehole only gets through the crust to the same depth as the mariana trench
<zid>
because you know, the pressure down there is like being in the mariana trench :P
<zid>
You need to actively cool all the drilling equipment, and it gets upset
<zid>
or.. molteny
<zid>
25C per km, it turns out
<gorgonical>
The next question is how much energy can you pump into the ground say 10k down before it creates a problem
<zid>
so after like 20km all your iron is starting to go soft :P
<zid>
I don't think it'd create a problem that we could like.. pin on it
<zid>
it would *change* things sure
<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
<zid>
but we'd never be able to attribute them
<zid>
"This pyroclastic flow moved by 1 milliarcsecond, then 20 thousand years later, this volcano went up here, instead of this one 400m away"
<zid>
climate change is an easy fix, anyway, we just run all our systems via capitalism, and it isn't interested
<gorgonical>
yeah it's not like black magic to solve. we just don't give a shit lol
<zid>
we could start sequestering the tens of billions of tonnes of carbon in huge cubes in a desert somewhere tomorrow
<gorgonical>
we're just trying to have our capitalism cake and eat it, too
<zid>
or refilling oil wells with carbon slurry or whatever
<zid>
we just need to *re* sequestor all of the carbon from all of the oil we extracted
<zid>
I like the idea of just painting all of everywhere with calcium nanoparticles
<zid>
Paint france.
<gorgonical>
An interesting question is what might happen if you did this with a desert
<zid>
deserts are pretty white already
<zid>
better to do it on all those car parks the US has
<zid>
France going to look like this when I'm through with it
<gorgonical>
I saw an interesting video where artificial opal changes light wavelengths to radiate energy directly, rather than reflecting it
<gorgonical>
So if you painted vast swathes of the sahara with this you'd radiatively cool the desert directly into space
<zid>
yea but it's already fairly good at that, you wanna do it on something with a lower albedo
<zid>
like car parks
<zid>
and rooves
<zid>
roofs
carbonfiber has quit [Quit: Connection closed for inactivity]
<zid>
albedo of sand is 30%, albedo of water is 10%, albedo of bitumen is 0.05
gog has joined #osdev
<gorgonical>
Sure, but the thermal emittance is also very important
<zid>
caco3 paint can go sub-ambient
<zid>
it's *very* good at it
<gorgonical>
So can opal paints
<zid>
opal is expensive
<zid>
this is just limestone
<gorgonical>
I guess my point is that we want somewhere with low albedo and high ambient temperature
<gorgonical>
But I don't know which is more important to prioritize
<zid>
they found the effect using barium oxide or something, then realized calcium oxide works fine too
<zid>
you make nanoparticles and it's just really really reflective to white light
xenos1984 has quit [Read error: Connection reset by peer]
<zid>
bounces that shit straight back into space
<gorgonical>
I thought that the opal nanoparticles also have like 90% thermal emittance, too
<gorgonical>
in the "into space" wavelengths
<zid>
yes but you *cannot* do this at small scales, or it does nothing
<zid>
caco3 is already industrially produced and probably at *least* half as good
<zid>
they gave up on barium because barium mining would cost more energy than it saved :P
<gorgonical>
but the ideas are exactly the same: reflect sunlight, and turn heat energy into light that will escape through the atmosphere
<gorgonical>
opal nanoparticles are probably just too expensive to be worth it at scale
<gorgonical>
like the barium
<zid>
that was my point, yes
<zid>
You want to paint something that's dark, and use paint that can be produced in the billions of litres/yr range
<zid>
titanium too expensive, I assume bloody opals are too :p
<gorgonical>
I am no industrial chemist so I have no idea whether the opal nanoparticle process scales
<zid>
(using price here as a metric for 'how difficult it would be')
<zid>
it's not really about how the *process* scales
<zid>
it's about how the *material cost* scales
<zid>
Lots of things are cheap if you want a global production of 10kg/yr
<zid>
but would be absolutely impossible at 1000kg/yr
<zid>
and make it cost a billion dollars per gram
<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')
heat has joined #osdev
<heat>
hello
<heat>
this gnu hurd thing, are we using it yet
<zid>
heat we're banning you from earth
<heat>
oh damn
<heat>
where am i going
<gorgonical>
space
<heat>
darn
<heat>
oh well
<Mondenkind>
i wanna go to space
<zid>
or deep in the mantle, we're counting that as 'not on earth' temporarily
<gorgonical>
well, really anywhere else but earth
<heat>
damn i have many many haters i see
<heat>
you know what they say
<heat>
if they hate you you're probably doing something right OR you're an insufferable asshole
<heat>
this web client is falling over yet
<heat>
isn't*. i do wonder if its something about chrome's memory saving or power saving shenanigans that are killing it
<heat>
it just loses track of the connection out of nowhere. really weird
xenos1984 has joined #osdev
Turn_Left has quit [Read error: Connection reset by peer]
<pounce>
gorgonical: are you at canonical now
<pounce>
what were your SAT scores
<zid>
low enough to think about burying hot
<zid>
I'm watching someone port .net to windows 95
<zid>
so I am clearly stupider though
thegrinchmann has joined #osdev
<mjg>
ey heat
<mjg>
check out geezers in action actively geezering a utility by adding fsync where it's not warranted
<bslsk05>
reviews.freebsd.org: ⚙ D44742 install: Always use a temporary file.
<mjg>
tool has an option to create file in place as is *or* create a temp file, fsync it and rename
<mjg>
they are changing the behavior to always use the temp file, whcih does make sense
<mjg>
this completely unnecessarily comes with teh fsync though, which they handwave away in the classic geezer fashion
<mjg>
quote: Atomicity is well worth the quite minimal potential cost here.
<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
navi has quit [Quit: WeeChat 4.2.1]
thegrinchmann has quit [Ping timeout: 240 seconds]
<gog>
zid: mattkc
<gog>
i just saw that on my feed
* mjg
hugs gog, 2 missisippis
* gog
squirm away
<gog>
mjg: i've been taking heroic doses of benadryl since last night
<gog>
i feel fucken great
<mjg>
read some romance novels
<gog>
no
<mjg>
i had a look at the romance novel subreddit earlier today