Benjamin Mayo:
Rising from the ashes, iTunes Remote has been updated with a new design and support for the latest device form factors. The icon is greatly improved. It went from a white roundrect with an inscribed circle and harsh geometric triangle to a simpler coloured gradient and neatly-rounded play symbol. It’s a nicer icon than the stock Music app now.
[…]
Looking slighter wider, what is the point of this app existing. Remote controlling your Mac’s iTunes app makes little sense in an era of AirPlay 2 and HomePod speakers. Also, Apple now has three separate places to find ‘media remotes’. There’s the iTunes Remote app, Apple TV Remote app, and the Apple TV Remote platter in Control Centre. Each of these tread on each other’s toes in different ways, but there’s not one app for everything either. It is messy.
I’m glad the app is still around, as iTunes on my Mac is the only device that has access to all my music.
Update (2018-06-28): Nick Heer:
Because my music library and bookshelf speakers are still connected to my Mac, I use the iTunes Remote app all the time. It’s nice to see this app updated.
Icons iOS iOS 11 iTunes Mac Music Remote.app
Gus Mueller:
I really do hope we see things from iOS move to the Mac, touch and Pencil support in particular. And the idea that “folks don't want to use touch on the Mac” is pretty dumb when you realize Apple sells a hardware keyboard for the iPad which works exactly the same way as a touch Mac would.
[…]
Well, what if they made it easier for other apps to possibly take their place or at least fill in the gaps until the giants can ship something? Where can we find a billion other developers that already have a codebase that's ready to be compiled on another architecture, because they don't have decades of legacy code to clean up?
And if you look at from this angle, UIKit for MacOS makes perfect sense. Even if it's only to potentially help with a transition, that may or not actually happen. It gives Apple leverage.
Brian Webster:
So I dove into the Frameworks folder in the latest macOS SDK and found a total of 147 frameworks listed there. Yikes! I went down the list and wrote down which ones I think could reasonably be jettisoned on an architecture switch (note that there would also be many APIs within various frameworks that could be tossed too, even if the framework as a whole sticks around).
Previously: Intel and the Danger of Integration, Apple Announces Marzipan for 2019.
ARM ARM Macs Catalyst (Marzipan) Mac
Andre Weissflog (via Joe Groff):
The worst case being tens- to hundreds-of-thousands of small C++ objects, each in its own heap allocation, pointing to each other through smart pointers. While such code is quite robust in terms of memory corruption (segfaults and corruption rarely happens, since most attempts are caught by asserts when dereferencing smart pointers), this type of ‘object spiderweb code’ is also dog-slow without obvious starting points for optimization, since the entire code is full of cache misses. Other typical problems are memory fragmentation and ‘fake memory leaks’ because a forgotten smart pointer prevents freeing the underlying memory (I call them ‘fake leaks’ because this type of leaks cannot be caught by memory debugging tools).
[…]
The gist is:
- move all memory management into centralized systems (like rendering, physics, animation, …), with the systems being the sole owner of their memory allocations
- group items of the same type into arrays, and treat the array base pointer as system-private
- when creating an item, only return an ‘index-handle’ to the outside world, not a pointer to the item
- in the index-handles, only use as many bits as needed for the array index, and use the remaining bits for additional memory safety checks
- only convert a handle to a pointer when absolutely needed, and don’t store the pointer anywhere
C++ Programming Language Memory Management Optimization Programming
SciresM (via Hacker News):
After doing some research earlier today into how the Switch gains authorization to play a given game online, I learned that Nintendo has implemented some very strong anti-piracy measures in this regard -- they can actually perfectly detect whether a digital copy of a game has been legitimately purchased.
[…]
In the gamecard case, Nintendo can detect whether or not the user connecting has data from a Nintendo-authorized gamecard for the correct title. This solves the 3ds-era issue of gamecard header data being shared between games. Additionally, there’s a fair amount of other, unknown (encrypted) data in a certificate being uploaded -- and certificates are also linked to Nintendo Accounts when gold points are redeemed. Sharing of certificates should be fairly detectable, for Nintendo.
In the digital game case, Nintendo actually perfectly prevents online piracy here. Tickets cannot be forged, and Nintendo can verify that the device ID in the ticket matches the device ID for the client cert connecting (banning on a mismatch), as well as that the account ID for the ticket matches the Nintendo Account authorizing to log in. Users who pirate games definitionally cannot have well-signed tickets for their consoles, and thus cannot connect online without getting an immediate ban -- this is exactly how I would have implemented authorization for digital games, if I were them.
Nintendo
Matt Diephouse:
Here’s the bug I fixed (with a lot of help):
7380.swift:1:16: error: type of expression is ambiguous without more context
"str"[keyPath: \.count]
^~~~~~~
That seems obviously broken. The value is a String literal. They KeyPath should obviously be String.count. So why doesn’t this work?
This is an interesting look at learning how to fix a bug in the Swift compiler.
Compiler Programming Swift Programming Language
Anastasia Ershova and Gerald Schneider (via Simon Hix):
By trying to replicate the results of a conditionally accepted article, we uncovered discrepancies between the reported results calculated by the author and the ones obtained by us. These divergences spurred an intensive exchange between the author and us and, finally, resulted in the discovery that they are due to changes in an algorithm used by the (commercial) software company for calculations done with a certain estimator. The software company, which pressures universities and research institutes to buy the expensive updates of their statistical package every second year at least, reports that it has since modified its algorithm. Yet, the company does not justify which version of the program is the correct one to use in order to get as close as possible to the underlying true relationship. It could be the case that the new algorithm saves us computing times, while the older versions calculate more accurate coefficients.
[…]
Researchers need to report which version of the software they used and, if this information is available, precisely when they last updated their software. In addition, they should be encouraged to replicate their findings with another software in the case that they are using a relatively newly developed estimator.
Science
