a pull request has been made, and already merged.

probably the joke is that in simulations you have a lot of parameters, so even though code is same, not all of them would result in physically realistic situations. or your params were so bad that you ran out of memory or processes killed your system or shit, so even convergence bit works.

also, uranium’s half life is 700 million years, so we expect (207/235)*7.5 (of lead) + 7.5 (uranium) ~ 14.106382978723405 lump.

also, a lot of the helium produced will remain trapped inside (most heavy metal lumps act as sponges for little gasses). but 700 mil years is also a large amount of time, so much of it would diffuse out. I could checkup diffusion statistics for he d pb-u but i would have to probably do a double integral (as pb-u combination is not fixed, and we can not simply do the error function calculation), so skipping that. but it is safe to say that we will have a lump of ~50% U, 44% pb, and 6% He (by mass), and a significant amount of he will remain in

this may very well be the case. I can not say for sure, my guess is that most cpus should be able to do something like 200mb/s zstd(3) uncompress, but you can try to benchmark uncompress speeds (there is also a zstd benchmark command), and if it is statistically significantly lower than your storage (use hdparam/dd to benchmark them), then it is indeed your cpu.

Other than memory speed, there is one more blocker - your cpu (ish). live usbs do not store the raw image uncompressed, they would be much larger in size. instead, the file system used (usually squashfs) is compressed (usually zstd (default level 3), but could be lz4, or xz, etc). whenever a file is loaded, it is first uncompressed, and if you have enough memory, you can try the load to ram (or memory, wording may differ) option, where, important parts of image are fist uncompressed and stored in memory, resulting in better performance. Now most cpus are fast enough to decompress, so limiting factor still is likely your storage (usb x.y standard) read speed (and if it stably runs that speed, or is thermally throttled), but if you are on a faster underlying source, it can make a difference.

Anecdotely, I use squashfs to compress most things i keep, and it is fast enough for most purposes, but i have observed that for benchmarks, especially single threaded, there is a significant difference. for geekbench 6, my singlecore score was close to 0.6 times of the actual score, when read from uncompressed, or from memory. for all core, score was nearly 0.85 times of the uncompressed/memory score. Would you realistically feel the difference, no imo. I even have a file system level compression (btrfs, zstd, level 3), and i do not feel a significant difference.

I have been using sudo-rs for quite some time, and no complaints about it

thankyou for encouraging. I will try out a bit. next thing to decide is topic to begin with, and how/where it would happen.

Imagine you are the one deciding, what medium would you prefer?

What i have been thinking is essentially a online meeting, like jitsi meet, which may be simultaneously casted online, or just recorded, and uploaded afterwards. people in meet would be able to ask, and hence it would be interactive. Whenever i have done courses, i have had like a billion questions, and if i do not ask, i do not understand, so i would not want anyone else to not be able to ask too. live chat is also interactive, but there is always a delay, and writing your doubts, is sometimes hard (you sometimes are so confused you do not know what to ask), so meeting helps with that.

in any case, if you need any help (for example course work or books), feel free to message me.

well vectors and matrices are both tensors, so and iirc, while writing by hand, we use lines to denote dimesions (1 and 2 respectively), and we use bold while typing

well i have learnt something, thanks. i usually just unitalicise names (so here, that would be moon and me, but not N, kg, m). I have seen units italicised a lot (professor notes, even papers), so i assumed it was accepted. i have seen normal ones too, and bold also (that is usually for vector quantities i think).

if i remeber correctly, it just slings most of fast moving things around (roughly equally in all direction), and only slow moving things actually hit it.

slung out of the system.

that seems a bit too strong for jupiter, that seems more like suns behaviour

Jupiter’s pull is so great, compared to earth, that the ones that do get past or then pulled more towards the sun.

this seems correct.

but i have not actually done any courses on celestial mechanics, and mostly basing on yt videos that i watch, so you maybe are correct on this one.

but jupiter also slings a lot towards earth too

they kinda are not. it is most likely typeset in latex, where in equation mode all letters by default get italicised. and it is kinda accpeted as appropriate typesetting.

what do you mean by efficient. I am using niri right now, and i do not record increased power/cpu/gpu usage as compared to sway.

I remember their appointment from brodie’s video on this, and iirc, they were someone who has been in community for ~20 years, and they also had some kind of vision disability (not 100% sure), because of which there was hope that gnome would do more investments on accessibilty front. Which to gnome’s credit, they have the best among other wayland folks, but this feels to sson. if it had been a year or 2, it would have made sense (they already were an old person, so time was not favoring them), because it is reasonable for such posts 2 change in that timeframe. the previous director also left in 5-6 months, then this person in 4, it really speaks something about gnome’s board