30 karma · joined November 28, 2016
Like rescheduling automatically a container on another server if a server is down? Deploying on the less filled server first if you have set limits in your containers?
And if they allow large IP ranges, one could try to spin up a virtual machine on the same cloud provider as the messaging platform.
Thanks
Hence why projects like this exist: https://github.com/Kaliiiiiiiiii-Vinyzu/patchright. They hide the debugging part from JavaScript.
This tool is like a guest book that people can write when they leave the guest house. These messages can be read by new guest and give inspiration or joy.
But maybe it doesn't exist and I should create it.
There are recommendations about the memory needed for compiling.
If you do not have enough RAM just use the docker image which is already precompiled.
Either youtube-dl or newpipe.
Not reporting the problems in the engines do not benefit to the users, if nothing works why use SearX in the first place then? I would even say it's a major advantage to have the ability to quickly and easily report the issue, this way the users are all getting quick fixes as soon as something break. We rely on unstable API or ways to extract the results from the engines, it doesn't make any sense to not have a system that allow to report the instabilities.
It is true that SearXNG code base change a lot faster than SearX one when it was still actively maintained, but that's because our users want to see the software evolve to new needs, and like I said above relying on unstable ways to extract the data require us to improve the software so that it still works with the engines we rely on. A major feature we added is the new anti bot available on the public instances, it allows having public instances that work with almost all the engines instead of getting errors all over the place because bots were abusing the instance.