The greatest weakness of Google Photos is that it has no real incremental, automated backup features. If it could incrementally sync over to other services, it would be much better. The closest is to manually use Google Takeout to export specific time ranges, and then copy those elsewhere.
That's me in a nutshell. I have close to 300GiB in Google Photos, mostly photos and videos of my children. I take a lot of photographs because getting a good shot, for me, is mostly a matter of luck. I don't delete that many photos because it's active work and I don't really care to spend the time. I do curate an album of decent ones, just so the few people who care can see new photos and videos every now and then. I pay a relatively small fee for 2 TiB of space.
This model has some significant downsides for humans, but less so for automatons. It eliminates some major problems of software development like merge conflicts, dependency hell, etc.
I still have my copy of Learning Perl. Mostly because it represents a milestone in my learning. I have kept and obtained a number of other books simply because they are antiquated, special and/or classics that are interesting to read even if they are not that useful to me, like Codd's relational book, or Calendrical Calculations. I hope the AI is trained on these sorts of books, so that the knowledge can live on in a different way.
I might be missing your sarcasm, but this is a common approach for large scale builds. Virtual filesystems are used to provide a pre-computed tree hash as a xattr. In a more typical case, you can read the git tree hash.
Not sure it was meant as sarcasm really. I just think so many build (and other) problems could have been avoided it a file hash was available on every file by default.
In the current POSIX paradigm yes, it would be expensive. But if the hash was defined as the hash of fixed blocks, it wouldn't be expensive. The raciness depends, a lot, on the semantics we would define. (In the context of a build system, it's no different than that the file could get a new mtime after we read the mtime.)
>The browser extension doesn’t work half the time. In addition to being frustrating, that makes it a less secure system, as one of the benefits is that it only fills the password on the specified domain. A lack of reliability of the extension leaves people more vulnerable to phishing, since they have to copy/paste passwords out of the app.
This is my main frustration with it as well. It is one of the main features in my mind, and it often does not work. It seems to work for many sites I use on desktop (Firefox on Linux, Mac), but doesn't work well at all on Android (Android app and Firefox). I can understand if this issue is outside of 1password's control because it possibly is due to specifics of Android's APIs, but I would prefer transparency in the matter.
reply