Google photos search doesn't work well at all for me.
Even things like "[my dog name] beach" isn't reliable.
Or things like I use photos as notes. It doesn't reliably recall things like cheese when I take pictures of cheese in various stores to remember what is sold where. Not even the name of the cheese; just cheese. Ditto spices.
Don't use the name - "Mr Floppy at the beach" is meaningless, but "dog at a beach" will probably yield a lot more.
I've found google photos search to be pretty good, and if it can't find something usually the map-mode is enough to pin it down (e.g. go to the beach where you took the photo and it shows you the photos from there)
I did just check, and "dog at beach" generates sub 20% recall for me. I go to the beach weekly with my dog, take lots of photos because I'm a dork, and that first query skips many weeks.
Also, I did add my dog as a known / named pet under the explore tab, which is why I thought the name should work.
I can make it work by picking out the beach via geo, but I think the whole thing illustrates how much better this could be. I'd like to be able to get responses to queries like
* [pet name] at [beach X]
* [pet name] with sand on face
* dead seal, or even just dead animal (pics on beach)
* seaglass (recall is poor there too until I manually added to a photo album)
* dent in car
* [spice name] (I take pics of spices to know which stores offer what)
etc etc. The only way I manage the thousands of photos I have now is by carefully sorting into hundreds of albums, which google also doesn't support well.
Amongst the many many deficiencies of the app (which, tbf, does work extremely well as a read-through cache and seems to back things up very well), it likes to surface spotlights of dead people and pets. Which is not at all what I want proactively surfaced.
I think the classification engine is likely just like 500 common object classifications. It's quite old and has been around for ages so I don't think it is currently as sophisticated as modern LLMs etc. So "sand" and "face" are probably fine, but "sand on face" might be tricky. No idea though - just guessing from my own personal experience
It was also hobbled quite hard near the start as they had a scare with searches for "gorilla" accidentally returning pictures of black people so they have probably turned all the safety knobs they have up to 11, even if that impacts recall.
> A circular economy of crypto does exist - it’s small vs. the speculation, but people do receive crypto and spend crypto without ever cashing out to fiat.
Can you provide examples that do not involve extortion or drugs?
Well i live in shitty country where trying to transfer USD or EUR is very dangereous and could get you a prison time and not that amount you think of, it just we want to buy things from Amazon. thanks to binance and other ways we could transfer money and buy things from out of borders.
If any of those people or businesses are located in the US or similar countries, they're either selling some of that crypto for taxes or just not reporting it.
Once people start receiving the scary and confusing 1099s next year from using Venmo et al. from Bidens new policy, crypto may seem preferable to some people. Pro taxists often underestimate the fear common people have of tax authorities.
Most of these 1099s are going out to people who owe little or no tax on the transactions, such as people who split restaurant bills worth more than $600 over the course of a year.
Transactions in most crypto are even more visible to the state than in normal banking, because they're in an uneditable public database that never loses history.
Crypto tumblers are a thing, and they make the public history unreadable. Bank transactions aren't public, but the government can get access, and stuff like money laundering is easier to detect than with crypto.
I’ll go further. All transactions should be public, especially those by government, all politicians, and anyone in a position of authority over others.
I overheard a conversation just this morning where a young man was explaining to his friend that he was from Chzechnya, not Czechia. This apparently resolved a lot of questions for the friend.
Frankly, I am a bit disappointed with the article. I fail to follow the argument that an encrypted header makes it easier to adopt HTTP/3 & QUIC because middleboxes cannot see the header. With HTTP/1.1 & TCP, the middleboxes should not be changing the TCP packets anyway, no?
Also, the author does not point out that QUIC builds on UDP instead of directly building on IP like TCP does.
Even though they arguably shouldn't, some middleboxes assume that protocols don't change. They have made it hard for protocols such as TCP and TLS to evolve without breaking things.
Similarly, middleboxes have made it unviable to deploy protocols that aren't TCP or UDP based.
I did not know that protocol ossification was a such a thing. Thanks for the link, it's an interesting article.
It says that middleboxes near the edge are more likely to be the cause of ossification. Are there any stats about that? Such as some manufacturers or software companies "infringing" on the end-to-end principle more often than others?
Not sure about stats but if you hang out in networking forums, you'll see netops complaining about bad implementations of protocols in their networking gear forever. This has been a huge problem in several protocols, everything from SCTP to IPSec to UDP RTSP.
Effectively as in "they have the same effect". The difference was stated in the comment that you replied to: One is for general memoization, the other just for functions. You can use useMemo exclusively if you prefer.
But it does reflect so much that’s wrong with the React development.
Creating a first class hook whose only purpose is to wrap another first class hook, all so you can pass in a function rather than a function that returns a function.
I hear what you’re saying. I think in the abstract it seems like an unnecessary helper function. But in a historical context it makes sense.
About a year before hooks was introduced it was discovered by multiple teams that inline anonymous JSX functions could create big performance issues. This was particularly felt in react native development. The solution back then was to do the whole .bind(this) to your callback methods in your react classes.
Because of this (my guess) is the react team wanted to make it extremely obvious how you could use closure state as opposed to private method callbacks when they went intro hooks, without teams having to worry about taking a performance penalty with inline callbacks. It was not obvious to me (and I’m sure many others) when hooks came out that you could memoize functions before rendering.
Again, I get the redundancy point and maybe at this point it could be deprecated but I think you have to think about where the community was before hooks.
Memoization is saving things in memory, it's a tradeoff of memory for fewer function calls. It doesn't work with all possible callback functions (because they need to be pure based on their inputs and dependencies for the saved values to still make sense), and also you don't always want to spend the memory on it (some smart memory use is going to be more performant than the function calls, too much memory use is its own performance problem).
The two hooks have different names because they make different trade-offs.
I don't think cow anology is very appropriate. Technology is moving fast (well not as fast nowadays but still pretty fast) and if you don't update your tools your work will be as obsolte as your hardware. If any of your hardware is touching the internet running obsolete stuff is a big security risk. Vivaldi browser ? Notepad? seriously...
reply