Archive for April 25, 2022

Monday, April 25, 2022

Elon Musk Buys Twitter

Twitter (Hacker News):

Twitter, Inc. (NYSE: TWTR) today announced that it has entered into a definitive agreement to be acquired by an entity wholly owned by Elon Musk, for $54.20 per share in cash in a transaction valued at approximately $44 billion. Upon completion of the transaction, Twitter will become a privately held company.

Elon Musk:

Free speech is the bedrock of a functioning democracy, and Twitter is the digital town square where matters vital to the future of humanity are debated. I also want to make Twitter better than ever by enhancing the product with new features, making the algorithms open source to increase trust, defeating the spam bots, and authenticating all humans. Twitter has tremendous potential – I look forward to working with the company and the community of users to unlock it.

Frank Thelen:

Inflation ;-)

Twitter: $44 billion (Elon Musk)
Slack: $28 billion (Salesforce)
LinkedIn: $26 billion (Microsoft)
WhatsApp: $19 billion (FB)
Skype: $8.5 billion (Microsoft)
YouTube: $1.65 billion (Google)
Tumblr: $1.1 billion (Yahoo)
Instagram: $1 billion (FB)

Casey Newton:

After the announcement, sentiment in the public Slack channels remained largely concerned and negative, employees told me. “I was kind of surprised how much people seemed like they were giving up,” one told me. “Big bummer.”

But in one-on-one discussions, responses were more tempered. Some employees I’ve spoken with are open to the idea that a private Twitter run by Musk stands a better chance of improving the service than would a public company beholden to its shareholders. They like the fact that he wants to eliminate harmful bots and bring more clarity to how recommendation algorithms work.

[…]

In the meantime, the other big question looming over all this is who will run Twitter day to day.

Update (2022-04-26): Jack Dorsey:

The idea and service is all that matters to me, and I will do whatever it takes to protect both. Twitter as a company has always been my sole issue and my biggest regret. It has been owned by Wall Street and the ad model. Taking it back from Wall Street is the correct first step.

In principle, I don’t believe anyone should own or run Twitter. It wants to be a public good at a protocol level, not a company. Solving for the problem of it being a company however, Elon is the singular solution I trust. I trust his mission to extend the light of consciousness.

Elon’s goal of creating a platform that is “maximally trusted and broadly inclusive” is the right one. This is also @paraga’s goal, and why I chose him. Thank you both for getting the company out of an impossible situation. This is the right path...I believe it with all my heart.

Greg Roumeliotis:

The Twitter transaction was approved by the company’s board and is now subject to a shareholder vote. No regulatory hurdles are expected, analysts said.

See also:

Update (2022-05-09): Mike Davidson:

Some people — although no employees I am aware of — seem to think this is the greatest news in the world. Some people think it’s the worst news they could imagine. Is it possible though that it’s neither? According to Costolo’s Razor, this is probably the case… but we can’t say with certainty until we know.

I have several things I’m very worried about, and also several reasons why I think things might turn out okay anyway.

Update (2022-08-25): Felix Salmon (Hacker News):

Elon Musk has a “right not to consummate” his acquisition of Twitter and a “right to terminate the merger agreement,” according to a letter from his lawyers to the Twitter general counsel Vijaya Gadde sent Monday morning.

How macOS Manages M1 CPU Cores

Howard Oakley:

macOS doesn’t provide direct access to cores, core types, or clusters, at least not in public APIs. Instead, these are normally managed through Grand Central Dispatch using Quality of Service (QoS) settings, which macOS then uses to determine thread management policies.

[…]

macOS itself adopts a strategy where most, if not all, of its background tasks are run at lowest QoS. These include automatic Time Machine backups and Spotlight index maintenance. This also applies to compression and decompression performed by Archive Utility: for example, if you download a copy of Xcode in xip format, decompressing that takes a long time as much of the code is constrained to the E cores, and there’s no way to change that.

[…]

In the original M1 chip, with 4 E cores, QoS 9 threads are run with the core frequency set at about 1000 MHz (1 GHz). What happens in the M1 Pro/Max with its 2 E cores is different: if there’s only one thread, it’s run on the cluster at a frequency of about 1000 MHz, but if there are two or more threads, the frequency is increased to 2064 MHz. This ensures that the E cluster in the M1 Pro/Max delivers at least the performance for background tasks as that in the original M1, at similar power consumption, despite the difference in size of the clusters.

Previously:

Update (2022-05-09): Howard Oakley:

In many cases, these appear to demonstrate that running code exclusively on E cores uses more energy, not less.

[…]

This result occurs because Activity Monitor, currently version 10.14 in macOS 12.3.1, doesn’t know the difference between processors with identical cores running at fixed frequency, and Apple’s M1 chips, with two different types of core and variable frequencies for each cluster of cores. Given that it’s now nearly 18 months since Apple started shipping its first M1 Macs, you might think that a little surprising. It’s even worse that Activity Monitor’s errors are discouraging developers from making better use of the cores in M1 chips.

[…]

Until Apple updates the figures returned by Activity Monitor for M1 chips, confounding by core type and frequency makes it not just useless, but actually misleading for comparing CPU % or energy. If you need to assess those, for example when considering whether to let the user change the QoS of threads in your code, the only reliable tool is powermetrics, which provides details of cluster frequencies and power use, as well as active residency.

Howard Oakley:

I show how you can get accurate estimates of power and energy use, and how the E cores in M1 chips can be far more efficient than the P cores. Today’s compression task required less than a third of the energy when run on the E cores, than on the P cores.

Update (2022-05-26): Howard Oakley:

  • In real-life use, E cores are normally managed by macOS to run at frequencies of 600 MHz (idle), 972 MHz (one or few threads) or 2064 MHz (multiple threads), with cluster power up to 621 mW.
  • When running macOS tasks, P cores are commonly used only in brief bursts at a wider range of frequencies, with cluster power up to 2,000 mW.
  • macOS strategy is to load E cores heavily with system tasks, and spare P cores for user tasks. This ensures the user is unaware of and unaffected by heavy system workloads. It also minimises battery use in notebooks.

App Store Removing Old Apps That Still Work

José Adorno (Hacker News, MacRumors):

Apple has been sending some developers an email titled ”App Improvement Notice,” warning that the company will remove from the App Store apps that haven’t been ”updated in a significant amount of time.”

As first reported by The Verge, developers have been complaining over social media about this new policy, as this could be harmful for indie and game developers. One of them, Twitter user Protopop Games, shared a screenshot of the email sent by Apple[…]

Their Motivoto app was last updated about two years ago, so it’s not that old.

Protopop Games:

I’m sitting here on a Friday night, working myself to to bone after my day job, trying my best to scrape a living from my indie games, trying to keep up with Apple, Google, Unity, Xcode, MacOS changes that happen so fast my head spins while performing worse on older devices.

Kosta Eleftheriou:

Meanwhile, some of Apple’s own apps haven’t been updated for much longer than that.

Rules for thee, but not for me!

Kosta Eleftheriou:

Apple also removed a version of my FlickType Keyboard that catered specifically to the visually impaired community, because I hadn’t updated it in 2 years.

Meanwhile, games like Pocket God have not been updated by the developers for 7 years now[…]

Steve Troughton-Smith:

The constant removal of older games from the App Store is just another bridge burned with game developers, who are far less invested in or tied to Apple’s platforms than app devs.

Harry McCracken:

The notion that all software will always be improved by changes has never been true. Apple is happy to sell music and movies that haven’t changed in decades!

Mark Hughes:

Note, currently all my old apps like Perilar, DungeonDice, etc. are off the store. They all still work. Apple wants me to pay $100 extortion, recompile a bunch of old code that maybe takes minutes, maybe hours or days of catching up to “modern” APIs, before I can resubmit.

And once they start requiring Monterey instead of Big Sur, I have to buy new hardware to even do that, my iMac just misses the deadline for support (but they still give me a notification a couple times a month to “upgrade” to Monterey, so smart & classy).

[…]

I have no problem with Apple’s 30% cut[…] But every other part of the App Store policy is so noxious, all that’s left are shovelware predatory gacha games from China, “social” (masturbatory pictures of yourself) network garbage, and AAA studio teaser games, but not the real games. And now they’re just gonna make it impossible to get anything from the good era.

Dave Sapien:

This has happened to me also (indie game dev) a few years ago. The number is about 20 or so games that have been removed by Apple because they hadn’t been updated in two years. The worked perfectly fine on all the new hardware/software and even work today.

On top of that, I know that there is another 30 or so apps I was involved in with clients that have also been removed.

These weren’t the biggest apps/games in the world, but they were all high quality finished products that had nothing wrong with them. Its just the cost of re-publishing each one out-weighed the return, so I didn’t have much of a choice sadly. I do have plans to re-publish some of them, however they have to take a back seat for current work.

All that to say, I have a large part of my portfolio of work that is no longer available to the public, which just sucks.

Nick Lockwood:

I’ve had several replies from people who say their apps were removed despite not using any tracking of any kinds, so I guess that isn’t it.

The biggest single issue with Apple’s behavior towards developers is the lack of communication. Would it really inconvenience them to disclose the reasons for these decisions, instead of making proclamations from an ivory tower and leaving us all to speculate about the rationale?

Frank Reiff:

Apple just wants everything to be built on their latest SDKs. If that means that millions of developers need to spend a few hours re-building working apps.. it’s a price Apple is willing to pay.

At the end of the day, the development organization simply doesn’t want to support anything but the latest SDK. Less work. Fewer bugs. Less variability. Good for them, somewhat bad for users, a huge pain for devs.. but that’s the hierarchy of needs: Apple, users, devs.

Thomas Fuchs:

Games for 40-year old platforms are easily playable today.

Games released 8 years ago on iOS? Lost forever.

Previously:

Update (2022-04-26): Craig Grannell:

Someone reminded me of this piece I wrote back in 2017. The games list is sobering. Of the 12 I highlighted, Muffin Knight was fixed, Devil’s Attorney and ElectroMaster were updated (much later), and Forget-Me-Not ended up on GameClub (itself seemingly now dormant). BUT…

Of those four games (out of 12), only two of them have been updated within the previous two years. So out of the initial dozen, only a third survived 2017’s Apple apps and games purge, and half of those are now presumably set for the chopping block.

Matt Sephton:

You’re missing the easy workaround for apps that do still work: resubmit the existing binary!

Update (2022-04-28): John Gruber:

We can watch really old movies today — movies that aren’t just years or decades old, but generations old. We can read works of literature that are centuries old. But we can’t play iPhone games that are three years old unless the developers constantly devote time and attention to making sure they keep up with latest SDKs every 2-3 years? Pixar doesn’t have re-render Toy Story every couple of years.

It’s a hard problem and I can see the upsides of Apple automating the clearing of truly abandoned apps from the App Store, but it seems like there ought to be a way for developers of not-updated-for-a-while apps and games to just log into Apple’s developer portal and hit a button to vouch that they still work and don’t need an update. Apple could then only cull the apps from developers who didn’t respond.

Nick Heer:

iOS also has a setting where the system will automatically remove infrequently used apps from your device and re-download them on demand. If these apps are removed, it means a whole bunch of rarely-used but functional apps could effectively disappear if you have not launched them for a while.

Update (2022-04-29): Matt Deatherage (Hacker News):

Every version of iOS contains boatloads of these multiple-version workarounds. They’re not hard to find, either.

[…]

On and on it goes across hundreds if not thousands of APIs multiplied by each new iOS version.

[…]

We think it’s entirely fair for Apple to say, at some point, “We’re not going to support apps that link against an iOS SDK made for phones the OS no longer supports.”

Apple has not said this, at least not that we can find, and that’s probably part of why the move to drop “outdated” apps from the App Store seems capricious and short-sighted. We strongly suspect that if you could look at data for all the apps scheduled for removal, you’d find that they all linked against something older than the iOS 12 SDK, or maybe even older than the iOS 11 one.

milderworkacc:

I think what this argument misses is the complete monopoly Apple has over distribution. This is not about backwards compatibility and tech debt, this is about distribution.

Yes, you can keep an old device around to use old apps or play old games. But to do that you must have preinstalled the old app, and that device can never be broken or reset, lest you lose the app.

The analogy to VHS is not a bad one, but when VHS players (and DVDs, and BluRays) stopped being current, all the old players and tapes didn’t stop working. That is the power that Apple has right now - to remove old apps from existence even for devices and operating systems that support them completely.

Guilherme Rambo:

I had to update a sticker pack I launched back in 2016, which doesn’t even have any executable code 🙃

Update (2022-05-07): See also: Apple’s Explanation for Removing Old Apps.

How RAM Affects Xcode Compilation Speed

Matt Gallagher:

Xcode alone can fill the RAM on a 16GB system. Yeah, okay, half of that is “Cached Files” (not app memory) so the effect is subtle. Incremental builds are 5% slower compared to a 32GB system but clean builds are about the same. (Blue is 16GB, green is 32GB, lower is faster.)

Everything takes different amounts of RAM based on the total RAM of the system. My 16GB system running Xcode shows 8GB “Memory Used” in Activity Monitor but the 32GB system shows 12GB. (The Xcode process shows just 586MB used, the rest spread around 822 other processes.)

Simulator + SwiftUI previews and all the RAM on a 32GB machine is used. Now, the 32GB machine beats the 16GB one by 10% or more. Don’t be too worried if you can afford only 16GB since the difference is never more than 25%, even with a standard spread of apps in the background.

Without a stopwatch, I can’t tell the two apart – both systems have been equally responsive. But now I’ll add a Parallels Windows VM in the background. An easy 30% performance win to the 32GB machine. Worse: the 16GB machine noticeably stalls when swapping between apps.

Do you need 32GB for iOS dev? No, but memory up to 32GB is rarely wasted when IDEs are involved, even the difference is subtle.

He measured this using an Intel MacBook Pro.

Previously:

Heterogeneous Swift Dictionary With Strong Types

Ole Begemann:

The environment in SwiftUI is sort of like a global dictionary but with stronger types: each key (represented by a key path) can have its own specific value type. For example, the \.isEnabled key stores a boolean value, whereas the \.font key stores an Optional<Font>.

I wrote a custom dictionary type that can do the same thing. The HeterogeneousDictionary struct I show in this article stores mixed key-value pairs where each key defines the type of value it stores. The public API is fully type-safe, no casting required.

This is also similar to what the new AttributedString type uses. URLResourceValues takes a different approach, using a struct with optional properties.