Emphasizing a central concept/theme is common with Japanese brands, restaurants, events, etc. The translation is often slightly peculiar.
For example the Osaka Expo theme is "Designing Future Society for Our Lives". Or the retail store f.k.a. Tokyu Hands says, "Our concept is 'Create your own life in your own way with what is available within reach.'"
I was working for a marine biologist applying computer vision to the task of counting migrating river herring. The data set was lousy, with background movement, poor foreground/background separation, inconsistent lighting, and slow exposures that created blurry streaks. Moreover, the researchers had posted the frames to some citizen science platform and asked volunteers to tag each fish with a single point—sufficient for counting by hand, but basically useless for object detection.
In desperation I turned to Mechanical Turk to have the labels redone as bounding boxes, with some amount of agreement between labelers. Even then, results were so-so, with many workers making essentially random labels. I had to take another pass, flipping rapidly through thousands of frames with low confidence scores, which gave me nausea not unlike seasickness.
> No longer providing updates to the device after just a few years when it's still perfectly fine.
This is a weird one to complain about because Apple leads the industry in supporting older devices with software updates. iOS 26 supports devices back to 2019. And they just released a security update for the iPhone 6S, a model released a full decade ago, last month.
The oldest Samsung flagship you can get Android 16 for is their 2023 model (Galaxy S23), and for Google the oldest is the 2021 model (Pixel 6).
We’re moving away from hardware and into software and longevity in this discussion but wrt “apple leads the industry in supporting older devices with software updates” i would point out that Red Hat is probably more of a beacon / industry leader here as the main promise of RHEL is 10 years of support and updates. But again we don’t ship hardware so I see the narrower sense that you’re making but still would like to push back on the idea that giant companies cannot continue to keep complicated legacy code bases secure and functional about 2x longer in most cases than what Apple has done
Main problem, not just from Apple, is that as phone tech gets standardized and more long-lasting the software support cycles have not gotten longer.
It is abysmal that Android phone makers still need to customize the OS so much for their hardware. Apple has no incentive for longer support cycles if Android does even worse on it.
It has always been like that since CP/M and commercial UNIX days.
Vertical integrations like everyone sell a product, a brand, a whole ecosystem experience.
If all OEMs sold the same CP/M, UNIX, MSX, MS-DOS, Windows software stack, on the what is basically the same hardware with a different name glued on the case, they wouldn't get any brand recognition, aka product differentiation.
Thus OEMs specific customisations get added, back in the day bundled software packages are part of the deal, nowadays preinstalled on the OS image, and so on.
I tend to look at technology prices in terms of cost per unit time of useful life.
If Apple continues to supply updates for six-year-old phones, iPhone 17 prices range from $11/month (base model iPhone 17) to $28/month (iPhone 17 Pro Max w/2TB storage), meaning it's only about 20% more expensive to store data on a RAID 10 array of iPhone 17 Pro Maxes running current iOS versions than on standard-tier S3 (not a relevant comparison, obviously, but it amuses me).
So I don't know what's reasonable, but Apple's policies certainly appear to be.
I'm still salty that Apple no longer offer battery service on my OG Apple Watch, however, so reason has its limits.
Suppose you always want to be running the latest iOS release, but you want to replace your phone as infrequently as possible. You would "only" have to have purchased 4 iPhones since 2007:
| Model | Launch date | Obsoleted by | Price
|-----------|--------------------|--------------|------
| iPhone | June 29, 2007 | iOS 4 | $399 (*price cut)
| iPhone 4 | June 24, 2010 | iOS 8 | $599
| iPhone 6 | September 19, 2014 | iOS 13 | $649
| iPhone 11 | September 13, 2019 | - | $699
Adjusted for inflation, the total for these phones is $3,287 excluding carrier contracts. Assuming the iPhone 11 will be obsoleted by iOS 27 in September 2026, this costs you about $14.29/mo.
I was a long time Android user - but I realised I was getting through 2 or more phones in the time my wife had one. They'd either become obsolete or just die. I reluctantly bought an iPhone on this basis - it's actually going to work out cheaper if I get 5 or 6 years out of it.
However, I find the iPhone keyboard so bad and the settings concept so muddled that I'm going to return to Android when this experiment is over. Probably not for another 4 years though!
If we're talking anecdotes, my wife changes her iPhone every 4 years because it gets worse and worse. Daughter does the same. I change my Galaxy every 4 years because it gets worse and worse as well. Not sure how some people can say their <insert beloved brand> holds forever, unless they don't really use it of course. No brand really keeps up with the requirements, unless all you do is make phone calls - which is why my dad still has a Sony Ericsson.
You know you can sell and replace your phone if you don't like it. Recent Pixels have 7 years of support and they don't die. That's what I'd recommend you get instead. You can even trade in your iPhone for up to $700 when you buy a Pixel. You really don't need to force yourself to use a phone you don't like, leave alone for that long.
> Upon being notified, the Smithsonian immediately sealed Sanborn's archives for 50 years to protect Sanborn's intellectual property rights.
Sanborn actually showed off some of his worksheets during a PBS interview years ago, which I assume are the same documents later given to the Smithsonian. At one point I looked into buying the B-roll footage to take a closer look at them, but I discovered enterprising Kryptos sleuths had already done so years before.
I encountered an interesting snag with the new UI while scrolling through Slack. Suddenly the glass Huddle button was glowing with a golden-yellow hue which drew my eye, but I wasn't sure why, it didn't seem like anyone had started a call...
It turned out I had scrolled the content such that a yellow smiley emoji was positioned directly underneath the Huddle button, and the glass effect dispersed the color to the edges of the control.
There is a long-established convention that Mac OS visually distinguishes "default" buttons from others to guide the user toward a certain action. A button that changes colors depending on nearby content subverts that expectation.
Although I should say I've been using Tahoe for a month and so far that has only happened to me once, it's also the only time in my entire lifetime of using Mac OS. Generally the UI is fine but it's definitely not the best-looking release. (Why does a random subset of menu items have icons now, exactly?)
As a teenager I reached out to the authors of RoboWar and asked if I could have the source code to help port it to Mac OS X. A trifling detail I omitted was that I had no clue how to write C, whoops. How hard could it possibly be?
I also received the sources to Despair from Lloyd Burchill, which I was similarly unequipped to port. But unfortunately I didn't upload it anywhere.
There's also the game engine World Builder by Bill Appleton (of SuperCard fame), which Alexei Svitkine re-implemented in Java at https://github.com/asvitkine/wage-engine. This was used by several puzzle-adventure games. One I remember fondly is A Mess of Trouble by Ray Dunakin, which has been separately ported to modern macOS at http://www.amessotrouble.com/.
There's also an open source implementation of the Riven game engine for modern macOS, https://github.com/jfroy/rivenx. Though the Myst series has since been re-released.
I'm hopeful this makes Nvidia take aarch64 seriously for Jetson development. For the past several years Mac-based developers have had to run the flashing tools in unsupported ways, in virtual machines with strange QEMU options.
iOS famously doesn't allow reloading themes or software. It's part of why they struggled to find a carrier to launch with in the beginning, because carriers modifying phones used to be the norm.
There are settings carriers can push to iOS (access to features like tethering, some network configuration stuff) but this type of malware cannot be pushed onto iOS. At worst, carriers push shitty Java applets to the (e)SIM, but that's all sandboxed off from any user interaction.
The two options are reach over all else, or control of its customers and overcharging them at every turn over all else.
One is not obviously better than the other, though I'll grant that Apple has managed to get their users to a place where being subjected to them has become a point of pride, which is impressive.
If we look iphone versus the direct google phones, both are quite expensive and at this point google's about $800/TB for storage upgrades is actually worse than apple's price.
Yes the Pixel phones are just as unaffordable as iPhones in this case, you're right! Google and Apple are the same here. If you want an inexpensive phone you must look for an Android phone that is not made by Google.
I think the structure of this article definitely made it harder to find the details to some of these questions—the fact that it's posted as 5-8 different "blog" entries instead of a single webpage made it harder then it needed to be to get to the technical conclusions section. Also, some of the method call listings on this page: https://www.benedelman.org/applovin-execution-path/ were unnecessarily verbose, and duplicative with the later pages that actually explained the flow in more detail e.g. https://www.benedelman.org/applovin-execution-sdk/
Having all of the sections of the article on the same page would have helped surface and resolve a lot of these potential editorial issues.
Thanks for these suggestions. You may be right. I split the article into pages based on feedback from early readers that it was too long. Custom nav bar in the top-right, but maybe still not quite right. I've never previously posted anything of this length or complexity.
Thanks also for reading so carefully. My web stats say many people stopped at the summary!
I was momentarily confused because I had commented out an importmap in my HTML with <!-- -->, and yet my Vite build product contained <script type="importmap"></script>, magically uncommented again. I tracked it down to a regex in Vite for extracting importmap tags, oblivious to the comment markers.
It is discomfiting that the JS ecosystem relies heavily on layers of source-to-source transformations, tree shaking, minimization, module format conversion, etc. We assume that these are built on spec-compliant parsers, like one would find with C compilers. Are they? Or are they built with unsound string transformations that work in 99% of cases for expediency?
This is the kind of thing that works until it spectacularly does not. XML parsing with regex is fine for simple, well-controlled cases but breaks as soon as you hit edge cases. We learned this the hard way trying to parse security questionnaire exports. Started with regex, ended up rewriting with a proper XML parser after hitting too many weird formatting issues.
I ran into one of the most frightening instances of this recently with Gemini 2.5 Pro.
It insisted that Go 1.25 had made a breaking change to the filepath.Join API. It hallucinated documentation to that effect on both the standard page and release notes. It refused to use web search to correct itself. When I finally (by convincing it that is was another AI checking the previous AIs work) got it to read the page, it claimed that the Go team had modified their release notes after the fact to remove information about the breaking change.
I find myself increasingly convinced that regardless of the “intelligence” of LLMs, they should be kept far away from access to critical systems.
I've found that when any of these agents start going down a really wrong path, you just have to start a new session. I don't think I've ever had success at "redirecting" it once it starts doing weird shit and I assume this is a limitation of next-token prediction since the wrong path is still in the context window. When this happens I often have success telling it to summarize the TODOs/next steps, edit them if I have to remove weird or incorrect goals, and then paste them into a new session.
Not to forget the energy and computational power wasted to get that answer as well. It’s mindboggling how willingly some people will let their brain get degenerate by handing out shallow debugging tasks to LLMs.
You could look at it as wasting your brain on tasks like that. You start off with a full cup of water each task takes a portion. Farming out thought to an llm can allow you to focus on the next task or the overall before your cup is empty and you need to rest.
I'm increasingly convinced that most of the people still complaining about hallucinations with regard to programming just haven't actually used any of the tools in more than a year or two. Or they ran into a bias-confirming speedbump and gave up. Agents obviously hallucinate, because their default and only mode is hallucination, but seeing people insist that they do it too much to be useful just feels like I'm reading an archive of HN from 2022.
Personally I think they are useful, but in a much narrow way than they are often sold as. For things I'm very familiar with, they seem to reduce my productivity by a good chunk. For things I don't want to do like writing some kinds of tests it's probably about the same, but then I don't have to do it, which is a win. For things I'm not very familiar with it probably is at least 2x faster to do with LLM, but that tends to diminish quickly. For example, I recently vibe coded a website using NextJS without knowing almost anything about it. Incredibly fast to get started by applying my existing knowledge of other systems/concepts and using the LLM to extend it to a new space. A week or so of full time work on it later I'm at the point where I know I can get most things done faster by hand, with the occasional LLM detour for things I haven't touched before
It depends on the model knowledge base and what you are trying to do. Something modern with the Buffalo framework in golang many hallucinations. A php blog written in 2005 no hallucinations.
I ran into many similar problems, sadly I don't think your example is an outlier. I had to write my own simple HTML bundler (https://github.com/jeff-hykin/html-bundle), not cause I want to or because I care about bundling, but just to know that it was done correctly.
This is why I basically never trust npm packages unless I know the authors, like the standard library from the Deno team, or people like Ryan Carniato or Evan Yu.
Fun thing to know - commented out code is still a node in DOM tree (with nodeType: COMMENT_NODE), so there shouldn't be a need for regex (if that's done via regex)
For example the Osaka Expo theme is "Designing Future Society for Our Lives". Or the retail store f.k.a. Tokyu Hands says, "Our concept is 'Create your own life in your own way with what is available within reach.'"