At the end of my geotech class the Prof put up a joke slide that said something along the lines of “now you should know the difference between soil and dirt”. We all looked at each other because no one knew. He didn’t teach us that. He was also a shitty Prof.
Serious answer: the sensors in telescopes and probes don’t work exactly like human eyes. They pick up a different range of frequencies than our cone cells in the first place, and don’t have the same sort of overlapping input curves. There’s a lot of tricks and techniques in converting an image into the same sort of thing we’d see with the naked eye. You can sorta think of it like translating Japanese into English; there’s no perfect formula and it requires some creative interpretation no matter what.
The popular images that get published all over are simplistic composites and never really reflect the actual data astronomers rely on, so that was never a hindrance to scientific progress. It suddenly made the news because a research group decided to reevaluate the old data and reinterpret it against calibrations from other equipment (e.g. Voyager probe vs. the Very Large Telescope here on Earth). There’s a general interest factor in “wow that looks so much different than the old pictures”, when the underlying data really hasn’t changed.
To add to this, we apparently always knew. The famous blue image is more or less the correct hue, but the saturation has been absolutely blown out like a clickbait youtube thumbnail in order to show faint features more clearly. Somewhere along the line we stopped mentioning that that had been done. Irwin and co just just re-calculated it to get the most accurate version yet, because we've got a lot more data to work with now than we did back when Voyager 2 did its fly-by
Sort of? My understanding from reading a handful of articles is that Neptune has a bluish haze layer that’s absent on Uranus, but it’s fairly subtle and the overall color of both is a pretty similar frosty light green. So it’s not just that it got oversaturated but that that particular blue hue got applied to the whole planet and not just a thin layer.
Furthermore, it’s not that the original scientists failed to produce true-color images. The original published images of Neptune had deliberately enhanced colors to better show some of the features of the cloud surface, and the description text of the images said as much. But that nuance was quickly forgotten and everybody just took the deep blue coloring to reflect the actual color of the planet, which spread to depictions of the planet everywhere.
As the white/gold versus blue/black dress debate showed, our perception of color is heavily influenced by context, and is more than just a simple algorithm of which rods and cone cells were activated while viewing an image.
I do not have any containers afaik, docker is not installed and podman ps --all gives zero results. I do use hombrew a little, have the following installed;
I have reported this over a week ago, in their help section, but have not gotten a lot of help with it, even though I have tried to document the process as much as possible. If I dont get any more help there, I’ll try to report it to the appropriate ublue channels.
might well be, I had one Fedora box through toolbox, but deleted that. But they still appear, so thats ruled out too. I dont use homebrew that much, so I could try to remove it to see if that changes anything.
Also, Podman --help states that ps is to list containers:
ps List containers
I have removed all containers and images prior to this as I thought that was the issue, but it seems like it is not.
From what I understand, zram only works on a small portion of the ram, and it used as essentially a buffer between ram and swap, as swap is very slow. It actually benefits systems with more ram, if anything. The transparent compression takes far less time than swapping data to disk
<span style="color:#323232;">podman system prune
</span>
See if it frees up any space. But it does seem like you’re running containers (which makes sense given you’re on an immutable distro) so I would expect to be using lots of temporary space for container images.
right so podman system prune does save some space, but not much. I still see the folders popping in right after having used the command. Also podman ps --all doesnt list a single container :<
My guess is that you’re using some other form of containers then, there are several. It’s a common practice with immutable distros though I don’t know much about bazzite itself.
Are these files large? Are they causing a problem? Growing without end? Or just “sitting there” and you’re wondering why?
Growing without and end, each file varies in size, one being bigger than the other, as I wrote in the description of the post. They will continue to stack up until it fills my entire 1TB SSD, then KDE will complain i have no storage left.
I dont have docker installed and Podman ps --all says I have no containers… So im kind of lost at sea with this one.
Those aren’t the only containers. It could be containrd, lxc, etc.
One thing that might help track it down could be running sudo lsof | grep ‘/var/tmp’. If any of those files are currently opened it should list the process that hold the file handle.
“lsof” is “list open files”. Run without parameters it just lists everything.
So - there are a few different types of resources podman manages.
containers - These are instances of an image and the thing that “runs”. podman container ls
images - These are disk images (actually multiple but don’t worry about that) that are used to run a container. podman image ls
volumes - These are persistent storage that can be used between runs for containers since they are often ephemeral. podman volume ls
When you do a “prune” it only removes resources that aren’t in use. It could be that you have some container that references a volume that keeps it around. Maybe there’s a process that spins up and runs the container on a schedule, dunno. The above podman commands might help find a name of something that can be helpful.
aha! Found three volumes! had not checked volumes uptil now, frankly never used podman so this is all new to me… Using podman inspect volume gives me this on the first volume;
Does all this also apply to distrobox? I don’t use podman, but I do use distrobox, which I think is a front-end for it, but I don’t know if the commands listed here would be the same.
I’m not terribly familiar with distrobox unfortunately. If it’s a front end for podman then you can probably use the podman commands to clean up after it? Not sure if that’s the “correct” way to do it though.
In any case, it’s the temporary file directory so it should be fine to delete them manually.
Just make sure that podman isn’t running while you’re deleting them, assuming it is podman.
Lemmy and other Fediverse applications use the ActivityPub protocol under the hood. The ActivityPub protocol has something called “groups”, which Lemmy uses as communities. So groups and communities are the same thing essentially but other software (like Mastodon) calls groups something else and not necessarily communities. But I’m not an expert.
slrpnk.net
Hot