They weren't banned, but adult websites were not why people bought the original iPhone. Neither the military nor porn were the drivers of smart phone adoption.
On what platform? It invoked WebKit always on iOS in the early days, html or not. On Mac, AppKit could import html to attributed strings before WebKit existed.
I wasn't close enough to that to know how long a world build took. Didn't seem like it was too crazy though. Incremental (non-world) builds of the OS come out every day.
I have this impression because I know the native controls are terrific at rich text, so for some reason that support isn't done in a way the author wants to use. The source code of the TextEdit app on Mac is actually published as an example project for the frameworks. Everything in there is provided by the native framework controls.
It would make sense, for example, if you wanted to allow editing of the rich text and have the markdown be directly accessible by the user. The conversion of markdown -> attributed strings -> markdown would not produce the same raw text, which is a problem if the user can directly edit or view the markdown. The user hitting cmd-B in the text view to make something bold might end up scrapping some explicit formatting they did to the raw markdown.
I enjoyed FiveThirtyEight back in the day, but does anyone actually go back and look at the old posts? They were very much of the moment. I'd imagine the vast vast majority of the traffic to them is robots.
I can see why they wouldn't be a priority to keep up. For archival purposes, I'd think everything is still in the internet archive?
Nate seems to try to justify this a touch, saying he personally was looking for a specific article. Kind of a special case there…
The Mac never used WebKit for NSTextField rendering. When iOS was first written, WebKit was used as the text renderer everywhere initially, including in UIKit controls (the “sweet solution”). This proved to be too heavyweight / cumbersome and the coretext/appkit text rendering approach was brought over.
The native Apple libraries are terrific at rendering rich text, it’s one of their strongest assets.
The poster’s issues seem to be specifically because they want to use markdown as the backing. The native rich text backing for native Apple views is attributed strings. They could translate the markdown to attributed strings, but seems like they don’t want to.
Most people making this argument aren’t saying they were incapable of doing the project without AI, they’re saying the cost benefit equation was unfavorable because it would take too long.
Ok, but not what this article is about at all. Six figures is for undergrads. The issue here is that PIs don’t have the money to support graduate students, who are typically fully supported.
I mean, this is semantics. Production is not the same thing as "important", but to me production code means customer facing. Internal tooling isn't production.
> No pure managers: Every leader at Coinbase must also be a strong and active individual contributor. Managers should be like player-coaches, getting their hands dirty alongside their teams.
What's the theory on this? It seems to be common conclusion, but I don't understand why AI changes the situation here.
I understand that AI means you can do more with fewer people. Fewer people means less coordination overhead and fewer managers and fewer layers. What I don't get is why you want your managers to be doing IC work more so with AI than before. I don't see why anything changes about needing roughly 1 first line manager for every 6-8 people, or why it would be more beneficial now that the managers have production programming responsibilities.
Both before and after AI it's important that managers have real technical knowledge of the codebase. Having managers do actual production IC work in my experience has been a bad allocation of resources, though, and I don't see why AI changes that.
(a) Someone has to do the management tasks. Why do we think that isn't a full time job anymore?
(b) When managers do production IC work, in my experience it increases the load on ICs in review, because the manager one would _expect_ to not be _as_ expert as pure ICs on the codebase, and yet they are perceived as "senior". ICs then have overhead in having to manage that power imbalance in review. I have known a few extremely productive manager/ICs… but the effect on their teams was not super great. It made the manager into something of a micromanager and the actual ICs lacked autonomy.
This has existed since the first version, except it needs to be signed with a valid apple cert.
A .pkpass file is a zipped directory that has a json file and some assets. There's no need to have a more limited version, a pass is already very limited.
The issue is spoofing. Major event ticketers are unwilling to publish passes if there's nothing to stop someone else from publishing a pass that is indistinguishable from their's and thus is an avenue for fraud.
The difference with events is that an ics file is not something someone's going to try to sell you or that you'd want to buy. But anyway, all Apple would have to do is stop checking the signing.
I imagine you're saying the capital return program is a mistake because they should reinvest the money in R&D etc.
I think the issue is there's diminishing returns to spending, and in some cases it can be outright negative. For example, one major thing you can do with money is hire more people. Hiring more people than you can handle is a great way to grind everything to a halt. You're basically making a bet when you hire that the additional capacity outweighs the danger of coordination failure.
Perhaps you could invest more money in fabs or something like that. I don't know, I'm a software person. But I did work at apple on software for 15 years, and I do not think throwing more money at software is particularly effective. The biggest teams at apple are often the least functional.