johnthuss

All your base are belong to us!

I found this video review to be much more informative and compelling.

https://youtu.be/6Wv1btxCjVE?si=_1mvIHT3r_CQsuTZ

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.

>> Apple TV+ is now simply Apple TV, with a vibrant new identity.

It's not the main point of the article, but it is there.

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?

This is a fantastic article! It's really eye-opening to someone like me who wasn't aware of these changes. Great job!

There was an excellent podcast covering this on Endless Thread!

https://overcast.fm/+PCa9DKnMg

Finally! This is incredibly good news. I hope the adoption of this feature is fast - looking at you Safari.

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.

Proofreading.

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.

This is great hard data to back up common perception. But I wonder how YouTube views for the Daily Show clips have changed over that same time period? Looking...

They are rarely over 1 or 2 million views on YouTube, so yeah, that's a big decline.

One big difference is that physical things exact an on-going tax since you have to store them in your house and maintain them. Hence the "does it spark joy?" question.

That said, the up-side is that physical goods can provide on-going benefit. For example, I love my AirPods Pro - they bring me joy every day.

research suggests that people are often happier when they spend their money on experiences rather than things

I concur.

Very interesting article! I was really interested in your pricing experiments!

The only cross-platform UI that is likely to be feasible to use long term is HTML/CSS/JS. That comes with significant downsides in terms of display fidelity. But that is going to be the case (to some degree) with any cross-platform toolkit.

At a small workplace an account can be shared by multiple developers to assist with programming tasks like generating code, improving code, writing unit tests, reviewing code, etc. The paid account was more highly available than the free one and also grants access the to newer GPT4 model. We have found it to be quite helpful.

I'm all for a shorter working week, but this would have a better chance if it was arguing for shorter days rather than another day off. That would be easier for companies to handle and would also be better for parents since they can have some extra time with their kids EVERY day and not just one day.

That's a great computer for development. I have the 16" version, but otherwise the same. It's fantastic, unless you need to do ML stuff, in which case you might want a PC with an Nvidia GPU.

What prompt are you using for summarization? I’ve tried several variations without consistent results.

I got the llama 65B model working on my M1 MacBook Pro, although not alpaca on top of it yet. The models are VERY slow unless you have enough RAM to fit them in. The 65B one is basically unusable with my 16GB of RAM (it produced about 8 words in 45 minutes). However, the 13B one works at a reasonable speed and the 7B is fast.

Note that the 65B model requires around 300GB of free disk space to prepare.

I followed the instructions here: https://github.com/simonw/til/blob/main/llms/llama-7b-m2.md