The Google Maps situation is a great example of why this will be hard. When Apple switched to their own maps it was a huge failure resulting in a rare public apology from the company. In order to switch you have to be able to do absolutely everything that the previous solution offered without loss of quality. Given Google's competence in AI development that will be a high bar to meet.
The ChatGPT integration was heavily gated by Apple and required explicit opt-in. That won't be the case with the Gemini integration. Apple wants this to just work. The privacy concerns will be mitigated because Apple will be hosting this model themselves in their Private Cloud Compute. This will be a much more tightly integrated solution than ChatGPT was.
The biggest NEW thing here is that this isn't white-labeled. Apple is officially acknowledging Google as the model that will be powering Siri. That explicit acknowledgment is a pretty big deal. It will make it harder for Apple to switch to its own models later on.
All while Waymo is expanding to more and more cities, including Detroit where it will deal with snow and ice. Waymo is years ahead of Tesla in the self-driving race. It's possible Tesla never succeeds in launching a truly self-driving car.
Amazon has their own PaaS offering called Elastic Beanstalk, with support for running docker containers and other popular platforms. It's not complicated to set up and is customizable if you need to tweak things. Any idea how Flightcontrol compares to this?
The use case I have encountered was for anonymous users where the company wanted to prevent unauthorized clients (copies of the app) from relying on the same server-side HTTP API used by the official app. The point wasn't to make it impossible for an unofficial to be used, but to make it harder than "trivial".
So the app used a digital signature / request signing with a key that was obfuscated and embedded in the binary. With anonymous users I don't know how else you could avoid use of the private API.
There are occasions where you just want to make it a little harder to impersonate an official client where it can be useful to store a secret in the binary. It's still vulnerable but requires intention and actual effort.
garble actually sounds like an excellent utility to add some protection around things like keys/secrets in a binary. Is there anything like this for Swift binaries?
An AI assistant lessens the fear of the blank page. It gets you started creatively so that you can work and it offers ideas which, even when they are bad, can lead you to something creatively satisfying. The important thing is that the AI is only an assistant and not the complete author. The human has to guide and tweak and rewrite a TON.
I write all my scripts with the hash bang as "#! /bin/bash" so even though fish is my interactive shell, I still use bash for all shell scripts. I think the restrictions you mention only apply if you use "#! /bin/sh" rather than bash specifically.
>>> This is
feasible in cases where the total number of distinct values in the
column 'a' is reasonably small (think tens or hundreds, perhaps even
thousands for very large composite indexes).
It's great this is improving, but this is a fairly narrow improvement. Personally, the multi-column indexes I use would not be improved by this change since column 'a' does not store a "reasonably small" distribution of values.
This is a super useful thing to know and I'm thankful for this article highlighting this aspect of Postgres.
But I would disagree with the takeaway to focus on optimizing your indexes and not your tables. The reason is that the order of columns in a multi-column index is highly meaningful and intentional in order to support match on a range of values for the last column in the index. The way databases work you can only utilize a multi-column index on (customer_id int4, date timestamp) if have an equality match on customer_id, like "WHERE customer_id = 1 AND BETWEEN '2024-01-01' and '2025-01-01'". If you reorder these columns in the index to put the larger date column first, then, sure, you save space in the index, but you also make it worthless – it will never be used by the query above. As such, optimizing a multi-column index is only useful when all the columns are queried for equality rather than a range.
In contrast, when you are creating a NEW table you might not think hard about the order of the columns in the table, and especially not about the data-sizes of each column and their alignment. But doing so at the time you create the table can be tremendously beneficial if it is going to be very large. It is important to note that you not only save space on-disk, but in precious RAM when the tuples are loaded.
> We now have smooth scrolling support in popular Java library called "awt." Many Java applications use this library underneath, including IDEs such as Eclipse, IDEA or Rider.
Eclipse doesn't use AWT, but rather uses SWT, a completely separate toolkit/API. That said, it's still great to hear that this is being improved.