An approach that's worked fairly well is asking Codex to summarize mistakes made in a session use the lessons learned to modify the AGENTS.md file for future agents to avoid similar errors. It also helps to audit the AGENTS.md file every once in a while to clean up/compact instructions
> Having described what I am worried about, let’s move on to who. I am worried about entities who have the most access to AI, who are starting from a position of the most political power, or who have an existing history of repression. In order of severity, I am worried about:
For how much this essay is being celebrated on Twitter, it's astounding how explicitly this section (The odious apparatus) decries China yet glosses over the US
> A coalition of the US and its democratic allies, if it achieved predominance in powerful AI, would be in a position to not only defend itself against autocracies, but contain them and limit their AI totalitarian abuses.
Sure, how about a thought on repressing its own populace with AI? I know the very next paragraph tries to cover this, but it all feels stuck in 2016 political discourse ignorant of the stench of rot and absence of integrity in American politics. This is especially ironic considering he calls this out as a risk later on: "if there is such a huge concentration of wealth that a small group of people effectively controls government policy with their influence, and ordinary citizens have no influence because they lack economic leverage"
----
The proactive thoughts in the Player Piano section are quite refreshing though. Hopefully other frontier companies follow suit
Because the DMA legally obligates them to share those APIs when they are necessary to implement a feature for a connected device. The goal of the regulation is to promote healthy competition for connected devices by outlawing self-preferencing by massive players. Reasonable people can disagree about the goals or the downstream effects of the DMA, but creating Private APIs for connected device features absolutely falls under the umbrella of self-preferencing.
In the same way, the EU could ask manufacturers of wireless headphones to open up and homologise their proprietary “APIs” with which they communicate with the other earpiece so you can mix&match single earpieces from different manufacturers.
The point of this regulation (DMA) is to enable more competition in important market segments. If this exact thing becames somehow very important, sure, it's possible, otherwise it's a bit contrived. What's the point?
Forcing standardization and interop is obviously good for interop, but it's bad for companies trying to innovate, because it ties their hands. The moment apple ships a v1 they have to ship an API, and then they have to support that API and can't change it. When it's private they can figure it out.
Apple already spends years in R&D before releasing anything. Many of their R&D devices never see market. Requiring them to share an API they've actually shipped to paying customers is not a significant additional hurdle. We know how to version APIs now. They can still make improvements to public APIs without hurting anyone.
Which is why DMA only applies to huge, dominant companies (the complete list: Alphabet, Amazon, Apple, ByteDance, Meta, and Microsoft) and there too it does not apply to all technologies, only for those where standardization is important to enable competition. It's much more important to have at least some competition than letting dominant companies monopolise entire markets through 'innovation' with private APIs.
Let's flip this. It's the user's device, providing the user's data to the user's headphones, via an app the user has chosen, that was written by a developer vetted by Apple, who's already reviewed and approved the code that will be running. And it's the law that they have to.
Because the user's device, providing the user's data to the user's Meta headphones, via a Meta app, can then record all the time and exfiltrate all that recorded data to Meta.
Or whatever other shady company wants to make headphones that sell for dirt-cheap in order to get their private spy devices into people's homes and offices.
I'm personally a bit on the fence about whether I think this is a sufficient concern to justify what Apple's doing, but AIUI this is the gist of their objection.
If it violates Apple's views on acceptable privacy practices, why are they approving the app? They already have guidelines against identifying information or collecting more data than absolutely required. The developer data use page is quite frank about the expectations:
Apps on the app store are held to a high standard for privacy, security, and content because nothing is more important than maintaining users' trust.
This is a rhetorical question, obviously. Apple is happy to stand on principle when it benefits them, and more than willing to soften or bend those principles when it'd be too difficult.
If a particular app only demonstrates this undesirable behavior when the phone is paired with a particular subset of headphones (or other hardware), then Apple may never notice it in App Review.
Because (since they control the platform/market) they're giving themselves an unfair advantage over competitors.
Example: iCloud photos backup can upload a photo to iCloud in the background immediately after it was taken. Competing cloud storage providers cannot do this[1], because Apple withholds the API for that. Of course they're saying this is for "privacy" or for "energy saving" or whatever, but the actual reason is of course to make the user experience with competing services deliberately worse, so that people choose iCloud over something else.
[1] There is some weird tricks with notifications and location triggers that apps like Nextcloud or Immich go through to make this work at least somewhat but those are hacks and it's also not reliable.
> Competing cloud storage providers cannot do this[1], because Apple withholds the API for that. Of course they're saying this is for "privacy" or for "energy saving" or whatever, but the actual reason is of course to make the user experience with competing services deliberately worse, so that people choose iCloud over something else.
Which makes Google Photos so much more impressive because it's heads above iCloud in this regard. No idea how they do that, pure magic.
Depends on your definition of a computer engineer. Dealing with strings in Python vs. dealing with character arrays in C is a world of a difference.
The decision to use Python feels like a solid compromise between giving the students a stair step to applied computer science work, while stripping away the cruft and language-specifics that would distract from implementing the more theoretical learning material
Depends on which part of the theory you care about. Lists in Python are a magic structure that can grow and shrink at will. That's a bit too high level to be useful for learning the theory.
Mermaid looks pretty for most applications and is quite easy to work with, but it starts to feel limited once you start playing with sequence diagrams. Had to bit the bullet and go with PlantUML instead for the time being, but rooting for Mermaid to gain a fuller feature set so I can fully move to it
People don't typucally drive at speeds they think are unsafe. When someone is speeding, they generally believe that they are capable of safely operating their vehicle on that stretch of road under the current conditions.
Avoiding the time wasted while pulled over does sound like a reason not to speed but even there it's a tradeoff. How much time do I save off my commute vs how long a stop would take weighted by the probability of being pulled over.
