The starting point is a notification from an app that you want to create a rule for. So you wait for a notification, then click on it in the "History" tab, and then you can configure the rest from there. It's slightly non-intuitive, but the reason for that flow is that the app needs the package name of the app, which almost nobody will know.
Is this for real, like do you really not see the difference? Not tryingto be snarky or sth, just struggle to comprehend this.
You compare apples to oranges here.
From a short look at the provided link, i guess it doesn'tcompare at all because it's something completely different?
Link you provided seems to be Samsung or OneUI only, integrated with Good Lock.
This seems to collect and present notifications together with the ability to search.
Does not seem to be open source.
DoNotNotify allows you to restrict apps to only sending you certain kinds of notifications.
They could supplement each other but you can't compare them as far as i'm concerned.
As is said, not trying to rude or sarcastic or anything.
I do not use any of the apps and just had a short look at the respective pages to see what they are. Both clearly state the repsective apps purpose, both have images of the apps.
I thought it was (in both cases) pretty clear what the respexctive app is and what not.
Not everything can be represented by textured meshes used in traditional photogrammetry (think Google Street View)
This includes sparse areas like fences, vegetation and the likes, but more importantly any material properties like reflections, specularity, opacity, etc.
It's criminally bad. You can't copy logged variables. You can't inspect worker threads (!?). WASM support is practically non-existant. You can't even do a heap snapshot on demand, something that should be a basic feature.
The timelines view is practically obfuscated with pretty graphs that show some aggregated data and some automatically generated snapshot points where the dev tools decide that are meaningful.
Inspecting the rendering pipeline is impossible. You can't see memory usage, compositing reasons, long frames (you kinda can but it's tricky)...
Not even going into remote debugging for iOS which crashes either the dev tools or Safari on iOS in any non-trivial scenario — the exact ones you need a debugger for.
That's fair, it sounds like you're dealing with some use cases I don't deal with often. And yeah remote debugging safari on an iPhone is pretty unreliable.
I studied ZKPs. You and I must have very different understandings of the actual scope of the problem. Like I said, everything that exists or is being worked on that makes a dent (including ZKPs) is incomplete or has ugly trade offs.
Maybe you are thinking purely from a math / theoretical perspective, but I'm thinking of a compete solution that's practical to use to solve the problem for sites like HN and many others.
That is true, and I'm also working in the industry.
We are currently in dire need of ZKP providers / abstractions that will aggregate both eIDs and tradition IDV (scans).
However it's extremely important that the technical capability is there. The next step is to build upon it, and I think that it's a great time for something like this due to all the horrible implementations of identity verifications currently available — that is 3rd party companies collecting scans of documents and biometrics.
reply