During one of my last Waymo rides the car stopped on Powell between Bush and Sutter (facing South stopping on the regular lane a bit before the Powell/Sutter crossing). This caused other drivers to drive on the cable car tracks to go around the Waymo (which are separated from the driving lane with a double yellow line) and it caused a truck to do a right turn directly from the cable car tracks (as there wasn't enough space to merge back into the lane).
Not sure if was legal or not for the Waymo to stop there, but given that Waymo stops take quite a bit longer than stops with Uber/Lyft (as it takes a while for the car to continue driving) this was one of the worst places possible to stop. Especially as there would have been space available right after the crossing next to Walgreens.
Yes. Most of the plans of the provider that I use in the US (T-Mobile) include free SMS and MMS to any country (also free data roaming in almost any country). I think it's similar for other providers (Verizon and AT&T), but I'm not sure as I'm not familiar with their plans.
> The best thing to do is for the city to own both fiber and electricity, and let providers compete for both.
Something similar is the case in the European Union, as the electricity network is usually a different company than the electricity providers. The network is often owned by some municipal company and charges customers only for the transport of energy over the network. For the energy itself customers can choose from dozens of different providers, some of them generate their own electricity, others just buy and resell electricity on the market.
With Google Voice I have a phone number not tied to a particular SIM card or to a particular phone. When I travel internationally I can use a cheap local SIM and I'm still reachable on my US number for calls and texts.
With Fi you run into issues if you use it for too long outside the US. And also I read that people had troubles re-activating a Fi eSIM from outside the US in cases where they (for example) lost their phone.
Did you have the number configured as forwarding number? At some point I got asked to verify an old forwarding number, but I just deleted it and Google Voice continued to work fine (I mostly use it in VoIP mode instead of forwarding calls).
For day to day use I use Apple Maps, but when hiking Organic Maps is my absolute favorite. A lot more useful than Apple Maps or Google Maps (as it includes routes that are missing in the other two) and it allows to add custom tracks which is super useful for navigation.
Slightly offtopic but related: One of my mobile providers supports configuring public (non firewalled) IP addresses for mobile devices and when choosing that option my phone battery drains very significantly faster than otherwise. I suspect it's because all the random packets that arrive every second or so on the public interface (when NAT and firewall are disabled) either cause the radio to use a lot more battery or prevent the CPU from going into sleep mode (or both of that).
For some reason lots of Android phones (even the Pixel models from Google) seem to use a whitelist approach that is quite restrictive regarding where VoLTE is supported. For example at least up until recently (and probably still the case?) Pixel phones only supported VoLTE in countries that were in the list of countries in which the Google store official sold Pixel phones.
Meanwhile newer iOS versions seem to nowadays have generic VoLTE (and even VoWiFi) support that even works for smaller MVNOs without an iPhone carrier profile (as long as their VoLTE implementation somewhat conforms to standards).
> Tangentially related, if you've ever had the pleasure of migrating away from Google Photos/Drive with Google Takeout, prepare to spend some time fixing photo metadata in your library and re-embedding exif data with exiftool. Takeout strips out the exif data into a non-standard JSON sidecar, as opposed to something more standard/well supported like XMP.
I heard this claim before but I was never able to reproduce it. Does this only happen with the "Storage Saver" option enabled and/or when metadata has been manually changed? At least with the "Original Quality" option my takeout data seems to exactly match the files that were originally uploaded.
My personal Internet connection is a bit too slow to wait for re-uploading all the data and my vserver doesn't have enough disk space to temporarily store all the data so I pretty much do everything in a streaming fashion: I use a Firefox extension that gives me the wget command (which includes cookies, etc.) when triggering a local download from Google Takeout, then I patch that command to stream to stdout, this first (tee-)pipes to a Python script that decompresses the data on the fly and dumps the hashes for each file into a log, and it also goes to "age" for encryption, and then to s3cmd for uploading the encrypted data to Wasabi.
For the comparison I pretty much only use the logged hashes which allow me to figure out if any hashes (and associated files) are missing in the new version of the backup. This isn't a perfect solution yet as a few things aren't detected. For example Google Takeout bundles mails in mbox files and I currently don't check for missing mails. It would be better to convert the mbox files to a Maildir first so that the comparison can be done on a per-mail basis.
I did not notice direct data loss yet, but I noticed other behavior that made me reconsider how much I trust it.
For example in the past I had several occurrences of duplicate photos where each of the two instances has exactly the same bytes as the other one. Usually that should have gotten deduplicated, but it hasn't. What's even stranger is that deleting one of the two pictures also deleted the other one. Re-uploading the original photo usually made both duplicates show up again. The way how I was able to get rid of those duplicates was to wait a day or so until I re-upload the data and to attempt that process several times. At some point only a single photo showed up.
Also those duplicates only showed up in the regular photo view. Even if both of the duplicate instances were added to an album viewing the album would only show the photo once.
This works fine for smaller accounts, but on larger accounts it seems to be regularly failing (based on my own experience and based on other postings and reports that I found online).
Exporting my Google Photos sometimes fails consistently even with lots of attempts. Out of well over 10 export attempts or so this year maybe a single one succeeded. I have a few hundred GB of data stored on that account. I also currently have a support ticket with Google open on that issue, but after initial follow-ups haven't received a response in a couple of months now.
That said my current approach for backing up things is to upload an "age" encrypted version of the data from Google Takeout to Wasabi. Once uploaded I run a script that shows me the diff between the data sets (so that I can ensure that no old data went missing that shouldn't have gone missing) before I delete older data. Probably not the most optimal approach though. Might be better to just set up some versioning layer on top of Wasabi and to keep deleted or modified data forever.
"and purpose built to run openpilot" would be the main issue here. Everything else is also required by a regular dashcam. The legal question here would be (and I don't know that answer to that) if someone distributing a hardware device that's optimized for a particular functionality without shipping that functionality, would be liable when users manually add that functionality to the device.
I didn't mean to say that they are not the owners, but that those two items (Comma devices and the software) are two different things.
Yes - Comma owns that repository and there are instructions on how to put the software on Comma devices. But then also lots of commits are from authors not affiliated with Comma and my understanding is that quite a few users of that software aren't actually using the official repository, but various forks maintained by third parties.
> Comma selling this product like it's some car accessory looks pretty reckless to me.
Comma is not selling openpilot (the software that makes your car self-driving), but they are selling the Comma devices that out-if-the-box just include dashcam functionality and a few additional features.
Openpilot is an open-source project on Github that makes cars self-driving and that also runs on regular Linux PCs as well as those Comma devices.
Do you suggest that Comma should not be allowed to sell the Comma devices anymore (that out of the box work as a Dashcam)? Or do you suggest that Comma should not be allowed to contribute to an open-source project that can make cars self-driving?
As add-on to this comment: There's another Lucene issue from 2 weeks ago that provides some more details on different approaches that were considered: https://github.com/apache/lucene/issues/12302
Even worse with transit in Vienna/Austria where if you buy tickets in advance for a specific day or date range they seem to take your local time into account if those tickets are bought while in another timezone. That's for tickets where time shouldn't even matter because they are for full days (from midnight to midnight).
If you're in Pacific time and you buy the ticket for a date in the future (let's say June 1st) before 3pm your local time everything works fine. But if you buy the same ticket for June 1st after 3pm Pacific local time (which is already the next day in Vienna) the ticket that you're buying isn't for June 1st but actually for June 2nd (only visible once you receive the confirmation).
So apparently they're somehow translating between timezones for the displayed dates, although that doesn't make sense: If I buy a ticket for June 1st on Vienna public transport I don't care what my local time is. Even if I'm in California while buying that ticket I still want it to be valid on June 1st instead of June 2nd.
Just a heads-up if you're planning to use passkeys with iOS/macOS: Might be fixed already, but last time I tried it out it seemed like iOS only stored a single passkey per domain. If you first store a passkey for a@domain and then later on store a passkey for a different user b@domain the a@domain passkey is overwritten without any warning. Or at least this seemed to be the case a couple of months ago when I tried it out.
Not sure if was legal or not for the Waymo to stop there, but given that Waymo stops take quite a bit longer than stops with Uber/Lyft (as it takes a while for the car to continue driving) this was one of the worst places possible to stop. Especially as there would have been space available right after the crossing next to Walgreens.