John Herrman:
It is, in other words, an industry now, one that Apple essentially gave life to and still dominates. Yet at this moment of triumph for podcasting, concerns are growing in the community about how much Apple actually cares.
Interviews with over two dozen podcasters and people inside Apple reveal a variety of complaints. The podcasters say that they are relegated to wooing a single Apple employee for the best promotion. That sharing on social media is cumbersome. And that for podcasters to make money, they need more information about their listeners, and Apple is in a unique position to provide it. The problems, they say, could even open up an opportunity for a competitor.
Marco Arment (Hacker News):
This New York Times article gets a lot wrong, and both podcast listeners and podcast producers should be clear on Apple’s actual role in podcasting today and what, exactly, big producers are asking for.
Podcasts work nothing like the App Store, and we’re all better off making sure they never head down that road.
[…]
Critically, despite having these large roles, Apple never locked out other players, dictated almost any terms to podcasters, or inserted themselves as an intermediary beyond the directory stage.
Federico Viticci:
The takeaway from the NYT story is that Leading Podcast Professionals would love ways to have more data about podcast listening habits as well as monetization features to sell access to podcasts via iTunes.
[…]
Right now, the iTunes Store for podcasts is essentially a glorified catalogue of external RSS feeds with show pages, charts, curated sections, and search. And that”s a beautiful thing: there’s little to no barrier to entry. Anyone can make their own podcast feed, host podcast files wherever they want, and Apple’s system will provide users (and other apps) with tools to search and subscribe from a unified location dedicated to podcasts. Ultimately, you own your podcast files, your RSS feeds, and the ads you sell.
Benjamin Mayo:
There’s a possibility Apple’s proactive involvement will be damaging. If I’m right about Apple’s motivation (influx of large corporations), then there’s a good chance independents will get shafted in whatever policies Apple implements. There’s also a chance that it’s a good thing. It’s not out of the question that Apple will add a storefront, so people can subscribe to shows for a monthly rate. Putting to one side the inevitable 30% cut, an easily-accessible subscription model Apple service could open up a new revenue stream for podcasts. More simply, Apple could also improve its podcast marketing and featured content efforts, potentially improving discoverability for good — but low listenership — shows.
Update (2016-05-09): Dave Mark:
It’s hard to make money creating content, whether it be writing, filming, or podcasting. There’s a temptation to hand over the reins, with the hope that a large platform will bring in infrastructure, detailed access to customer usage patterns and, most importantly, a steady paycheck.
Update (2016-05-12): See also: Upgrade.
Update (2016-05-13): Tim Schmitz:
Those responses did a great job of covering things from the podcaster’s perspective, but there’s something else bothering me as a listener. It’s a feeling that podcasting as it stands today, a medium that I get a great deal of enjoyment from, is about to change for the worse. Regardless of whether Apple or any other company caves to their demands, it’s clear that the Big Media world is coming for podcasts, and that doesn’t sound like a good thing.
[…]
In fact, the only changes I’m likely to see (hear?) as a listener are ones that will make my experience worse. Suppose, for example, that some shows become exclusive to tailor-made podcast clients that provide analytics data that others don’t. That only makes my life harder.
Advertising Apple Business Podcasts Privacy
Filip Pizlo (Hacker News):
Compared to OS-provided locks like pthread_mutex, WTF::Lock is 64 times smaller and up to 180 times faster. Compared to OS-provided condition variables like pthread_cond, WTF::Condition is 64 times smaller. Using WTF::Lock instead of pthread_mutex means that WebKit is 10% faster on JetStream, 5% faster on Speedometer, and 5% faster on our page loading test.
Making WTF::Lock and WTF::Condition fit in one byte is not easy and the technique behind this has multiple layers. Lock and Condition offload all thread queueing and suspending functionality to WTF::ParkingLot, which manages thread queues keyed by the addresses of locks. The design of ParkingLot is inspired by futexes. ParkingLot is a portable user-level implementation of the core futex API. ParkingLot also needs fast locks, so we built it its own lock called WTF::WordLock.
[…]
Adaptive locks combine parking and spinning. Spinning is great because it protects microcontention scenarios from doing parking. Microcontention is when a thread fails the fast path lock acquisition because the lock is not available right now, but that lock will become available in less time than what it would take to park and then unpark. Before WTF::Lock::lock() parks a thread, it will spin 40 times, calling yield between spins.
[…]
One advantage of OS mutexes is that they guarantee fairness: All threads waiting for a lock form a queue, and, when the lock is released, the thread at the head of the queue acquires it. It’s 100% deterministic. While this kind of behavior makes mutexes easier to reason about, it reduces throughput because it prevents a thread from reacquiring a mutex it just released. It’s common for WebKit threads to repeatedly acquire the same lock.
[…]
It’s clear that the OS mutex is doing exactly what it set out to do: no thread gets to do any more work than any other thread. On the other hand, WTF::Lock does not guarantee fairness. Analysis of the algorithm shows that a thread that has been waiting the longest to get the lock may fail to get the lock and be forced to go to the end of the queue. But this chart shows that even without having a fairness guarantee, the unluckiest thread using WTF::Lock got better treatment than any thread using the guaranteed-fair mutex. It’s almost as if the OS mutex is not actually fair because while thread 1 is served equally to thread 2, all 10 threads are underserved relative to a hypothetical thread 11, which is using a different algorithm. Indeed, we can think of thread 11 as being the OS context switch handler.
Concurrency iOS iOS 9 Mac Mac OS X 10.11 El Capitan Optimization Programming Web WebKit
Matt Gallagher (tweet):
I rewrote the C++ implementation of Swift’s Demangle.cpp in Swift. My reimplementation is completely standalone and can be dropped directly into any Swift project.
[…]
From the first line, we can see a difference between the Swift and C++ versions. Swift has a standard set of protocols and constraints for defining data providers, so it makes sense to use them. C++ could use a template parameter to define the data provider but since C++ lacks an equivalent to Swift’s protocol constraints and lacks a corresponding set of standard behaviors, the mulitple constraints for the data provider would be a confusing black box thrust upon any user of NameSource – likely manifesting in weird errors in internal headers if any requirements were not met.
[…]
But the most visible difference in adopting Swift error handling is a significant reduction in code size. Switching to Swift error handling immediately eliminated 149 return nullptr early exit lines from the C++ version. Furthermore, Swift can happily exit from a function in the middle of an expression when a parse attempt fails instead of needing to break expressions into multiple pieces either side of early exits.
[…]
Many large C++ projects – Swift included – are compiled with C++ exceptions entirely disabled. Why deliberately remove a potentially useful feature from the language? The Swift developers answer this question when considering error handling options for Swift[…]
[…]
This shows the advantage of a two value switch being idiomatic in Swift: compared to the strange series of #define, if and switch constructions in C++, this is clear, simple and readable.
He downplays the usefulness of the project, focusing on the code comparison with C++. However, I think the code is actually very useful because I want to record readable stack traces when throwing or propagating an error.
Update (2016-05-09): Cédric Luthi mentions the built-in _stdlib_demangleName(), but I think it’s private API.
C++ Programming Language Exceptions Language Design NSError Open Source Parser Programming Swift Programming Language
