The safety_checker.py package under the venv/lib/python3.xx/site-packages/diffusers/pipelines/stable_diffusion/ directory is where the actual image check for content is made.
The distributed model running in the background is setup in venv/…/accelerate/utils/fsdp_utils.py.
The ghost tty is in …/cachetools/func.py
Start searching for these same connecting packages in home, and watch how stuff starts lighting up in flatpaks…
safety_checker is indeed an ai image content check that ships with ComfyUI. There are two instances of it under the ComfyUI directory. Nowhere else on my $HOME
fsdpy_utils is also part of ComfyUI, it’s a module to help run models (not a model itself those are huge). ComfyUI is a webUI to run AI stuff, so it’s expected to be found there. It’s not found anywhere else on my $HOME
cachetools/func.py is a module providing cache not a tty. It exist in other Python software that I 've installed. No random instances of it all over $HOME either
You are probably asking an AI chatbot to produce drivel with technical terms you 've seen online to troll this community. It’s probably convincing to people who are unfamiliar with python, ai or linux but it does not pass inspections by anyone familiar with these things.
I think the distributed model used is in the venv under google/ai/. There appear to be json files in the googleapiclient repo that may contain the instructions used by the distributed model. I thought this was odd but likely just google crap in the json files related to telemetry. When I put this google repo on another drive entirely and disconnected it, there was a long list of warnings in ComfyUI that popped up about these when starting the server. Some of them are different than the rest. Some appear to be related only to the google online API, but some pages are more locally oriented.
If you search the sqlite3 database for ComfyUI using sqlite3 comfyui.db ".dump" and look at the entries at the bottom, these fields are what I searched for elsewhere. They somehow lead me to the google packaged stuff IIRC. These in turn lead to the locations mentioned previously and others within ComfyUI. I do not have an overview perspective to fully connect these dots. IIRC, there was a chain of obfuscation related to writing content to these entries in the database.
I also locked down Python, and boltctl in /usr/bin, and locked down /usr/libexec/uresourced to root. That seems to have altered behavior.
It appears that my modeling of a road bicycle shifter is a shape close enough to a gun to also trigger the same mechanism from FreeCAD where there was a similar x-pypi package sent with archive.
In the google api repo, there are tools for gcode and pretty much every other language or system.
I still have three processes on my system with no labels that appear to be related to the three archives, but I have no idea how to kill them. Nothing I have tried has worked. They appear to be connected to systemd-userdbd, but I have no way to know this is true. They are just three processes without labels that appear to only show up because of the SELinux context. Every other command claims they do not exist at the pid. They only show up with ps -eZ.
Lol. Good luck buddy.
The safety_checker.py package under the venv/lib/python3.xx/site-packages/diffusers/pipelines/stable_diffusion/ directory is where the actual image check for content is made.
The distributed model running in the background is setup in venv/…/accelerate/utils/fsdp_utils.py.
The ghost tty is in …/cachetools/func.py
Start searching for these same connecting packages in home, and watch how stuff starts lighting up in flatpaks…
Why would I need luck?
safety_checker is indeed an ai image content check that ships with ComfyUI. There are two instances of it under the ComfyUI directory. Nowhere else on my $HOME
fsdpy_utils is also part of ComfyUI, it’s a module to help run models (not a model itself those are huge). ComfyUI is a webUI to run AI stuff, so it’s expected to be found there. It’s not found anywhere else on my $HOME
cachetools/func.py is a module providing cache not a tty. It exist in other Python software that I 've installed. No random instances of it all over $HOME either
You are probably asking an AI chatbot to produce drivel with technical terms you 've seen online to troll this community. It’s probably convincing to people who are unfamiliar with python, ai or linux but it does not pass inspections by anyone familiar with these things.
I think the distributed model used is in the venv under
google/ai/. There appear to be json files in thegoogleapiclientrepo that may contain the instructions used by the distributed model. I thought this was odd but likely just google crap in the json files related to telemetry. When I put this google repo on another drive entirely and disconnected it, there was a long list of warnings in ComfyUI that popped up about these when starting the server. Some of them are different than the rest. Some appear to be related only to the google online API, but some pages are more locally oriented.If you search the sqlite3 database for ComfyUI using
sqlite3 comfyui.db ".dump"and look at the entries at the bottom, these fields are what I searched for elsewhere. They somehow lead me to the google packaged stuff IIRC. These in turn lead to the locations mentioned previously and others within ComfyUI. I do not have an overview perspective to fully connect these dots. IIRC, there was a chain of obfuscation related to writing content to these entries in the database.I also locked down Python, and boltctl in /usr/bin, and locked down /usr/libexec/uresourced to root. That seems to have altered behavior.
It appears that my modeling of a road bicycle shifter is a shape close enough to a gun to also trigger the same mechanism from FreeCAD where there was a similar x-pypi package sent with archive.
In the google api repo, there are tools for gcode and pretty much every other language or system.
I still have three processes on my system with no labels that appear to be related to the three archives, but I have no idea how to kill them. Nothing I have tried has worked. They appear to be connected to systemd-userdbd, but I have no way to know this is true. They are just three processes without labels that appear to only show up because of the SELinux context. Every other command claims they do not exist at the pid. They only show up with
ps -eZ.