Anomaly reshared this.
Anomaly reshared this.

Unfortunately, AI is gaining ground in almost every environment
Orca AI’s SeaPod
The system should help reduce the risk of collision at sea , the AI assesses imminent risks and warns the operator (Bridge Officers on watch)
The system consists of 8 ultra high resolution cameras, a monitor, and a computer (Ubuntu Desktop with Nvidia GPU) , and It is not connected in any way to the ship's automation.
As we know artificial intelligence, it must learn, it must be trained. This system processes more sources of information, and gets smarter every day.
Binary Lab Channel reshared this.
Anomaly reshared this.
youtu.be/a-r6GUYmv0Q?feature=s…
Concords first commercial flight 1976. Some have dismissed as some kind of lens flare. I am not so sure. Interesting anyhow. Make up your own mind:)YouTube
As questions remain over how the tanker collision happened, here is a timeline of how it unfolded.Vicky Wong (BBC News)
Anomaly reshared this.
The mayor of the Russian capital called the attack the war’s largest against the city. It appeared to be a reminder of Ukraine’s power to strike as its president proposes an air truce.Marc Santora (The New York Times)
Anomaly reshared this.
Hello , @Friendica Support
It's been more than 2 months since UpdateContacts the one highlighted in red it doesn't end , can you tell me how i can remove it?
Thanks
Friendica Support reshared this.
@Anomaly Deferred tasks aren't currently running. They failed during they initial run, which placed them in this wait list with a next try date in the future. From your screenshot it appears that the task creation date and the next try date are pretty close to each other, so it must only have failed a few times at most.
Running either the worker or the daemon manually will not clear deferred tasks which next try date have not been reached yet. There's an incremental back off system that increases the delay before the next try after each new failure. Once the task succeeds, the task will clear from the deferred list.
like this
Friendica Support reshared this.
pasjrwoctx👽 likes this.
Friendica Support reshared this.
Who remembers Beverly Hills 90210 , It was one of my favorite TV Show . It's been almost a year since Shannen Doherty (Brenda Walsh) passed away ♰ July 13, 2024 💔 .
#tvshow #beverlyhills90210 #shannendoherty
GrapheneOS
in reply to GrapheneOS • • •GrapheneOS
in reply to GrapheneOS • • •GrapheneOS
in reply to GrapheneOS • • •GrapheneOS
in reply to GrapheneOS • • •GrapheneOS
in reply to GrapheneOS • • •GrapheneOS
in reply to GrapheneOS • • •GrapheneOS
in reply to GrapheneOS • • •GrapheneOS
in reply to GrapheneOS • • •GrapheneOS
in reply to GrapheneOS • • •Source code is available here:
github.com/GrapheneOS/platform…
It's new code and still being built out so it hasn't had much refactoring, optimization or tuning yet. It's a mix of Kotlin and Rust since we wrote position estimation in Rust for significantly better performance.
GitHub - GrapheneOS/platform_packages_apps_NetworkLocation
GitHubc
in reply to GrapheneOS • • •GNSS uses a lot of battery
GrapheneOS
in reply to c • • •cedric_cvl
in reply to GrapheneOS • • •@cina
Thanks
So for Organic Maps, how should the "gplay location services" toggle now be set ?
GrapheneOS
in reply to cedric_cvl • • •@cedric_cvl @cina It will work either way as it did before. If you have the default of rerouting location requests enabled for sandboxed Google Play, both ways will use the OS location service.
If their toggle is off, it uses the AOSP fused location provider. If it's on, it tries to use the Google Play location provider which we reroute to the OS location services within the app based on the power level. It uses high power so it's GNSS + network location via fused. It's the same thing.
cedric_cvl
in reply to GrapheneOS • • •topcaser
in reply to GrapheneOS • • •GrapheneOS
in reply to topcaser • • •LinuxOS
in reply to GrapheneOS • • •GrapheneOS
in reply to LinuxOS • • •@3c6abbd464be07a16903dbfd2db475c628e6fdee4aacc845bbe60be2a5954853 This thread explains how our network-based location service works. It's better than the Google network-based location with server-side position estimation. It has partial offline support already based on the cache and will have full offline support in the future.
GNSS is receive only so that's best for privacy but you can't always get good enough GNSS signals and it uses a lot of power. A-GNSS is usually used to accelerate it.
GrapheneOS
in reply to GrapheneOS • • •@3c6abbd464be07a16903dbfd2db475c628e6fdee4aacc845bbe60be2a5954853 PSDS and SUPL are the A-GNSS features supported by AOSP and GrapheneOS. PSDS are static database downloads, so there's essentially no privacy impact from that since it's just the same as fetching app or OS updates.
GNSS + PSDS works pretty well.
SUPL is essentially a rough form of network-based location. We plan to eventually provide our own SUPL service and offline support as an extension of our network-based location service.
GrapheneOS
in reply to GrapheneOS • • •@3c6abbd464be07a16903dbfd2db475c628e6fdee4aacc845bbe60be2a5954853 GNSS + PSDS + SUPL is extremely fast to get a location lock with a decent signal. It may only 3 to 10 seconds. GNSS + PSDS without SUPL may take 10 to 30 seconds. GNSS without even PSDS could take minutes to get a lock and is more like pre-smartphone standalone GPS units without for any A-GNSS.
GrapheneOS adds toggles for PSDS and SUPL. Disabling SUPL is a privacy tradeoff. PSDS just downloads a file regularly, no real tradeoff.