wispy_jsp

https://help.kagi.com/kagi/search-details/search-sources.html

They use many sources, including other search engines and specific websites, but also claim to use two of their own indexes.

Can't say much in regards to perplexity, but I find kagi's index to be quite nice. Especially if you find fortune forum posts helpful (which I do as a software dev). It's paid only, so there's no advertising incentive to the company and also a ton of configuration. I search a lot, so I went with the 10 dollar plan. 5 bucks gets you 300 searches a month, 10 is unlimited plus access to their LLM which documents information sources like perplexity.

Personally, I found perplexity to be quite annoying with the more ai focused UI and trying to learn your interests. Kagi is a search engine first plus some other features they're developing.

Doesn't Israel have required military service?

And there's also WARs for servelets, uberjars, various means of bundling for exes, native compilation via Graal. Overall quite the ignorant meme.

They likely buy leaked data that would include things like your full name and email, perhaps an address. Even if an address isn't there, legal data brokers often have your address for a small payment anyways. From there they likely use something like Google Street view.

On the android front, if you don't mind using a pixel phone then Graphene OS would be worth checking out. It's a foss non rooted alternative to base android with a focus on privacy and security. The no root requirement means a good amount of apps like banking work properly on it. It vastly expands the app permission system and removes the special privileges to Google system apps, allowing you to remove it or limit them. It also supports sandboxing of the play store and multiple profiles so you can effectively quarantine Google requiring apps.

There's a huge amount variety between the alternative sbc providers, but I'm general:

• some are simply designed not to have various bits of hardware like the camera 22 pin connector.
• some fail to conform to the pis pin out or footprint, so hats won't be compatible
• more commonly, documentation and support is so poor that extensive dev/Linux experience is required to get existing hardware to work

All of this makes it difficult to utilize alternatives without conducting considerable research into many different ones.

Yep! That would be an example of serialization. In computer science, taking an applications representation of a data type/object and formatting it as a series of bytes for storage or transmission over a network is referred to as serialization, with deserialization being the opposite process.

In your case, I would definitely try out the ResourceUID class as it seems like it may fit your needs. You can use it to create and id and store that with the other fields in your custom data type. It returns an int so it will be very easy to use as a key in a dict. Just be sure to call add_id after creating so ResourceUID won't generate duplicates: https://docs.godotengine.org/en/stable/classes/class_resourceuid.html#class-resourceuid-method-add-id

Is there a reason you don't want to serialize that data with the nodes that use them? Are those values intended to change when the entity isn't loaded into a scene (like a background simulation or something)?

Seems like adding your own uuid or tapping into the ResourceUid class might be your best option

What is your use case? That would help narrow down a good solution. Node path could likely work. You could also add a uuid or similar (there's an extension that provides a uuid implementation). Might be hacky, but you could tap into this and see if it suits your needs https://docs.godotengine.org/en/stable/classes/class_resourceuid.html