And there's also WARs for servelets, uberjars, various means of bundling for exes, native compilation via Graal. Overall quite the ignorant meme.
wispy_jsp
joined 10 months ago
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
Doesn't Israel have required military service?