Republicans in Congress just voted to reverse a landmark FCC privacy rule that opens the door for ISPs to sell customer data. Lawmakers provided no credible reason for this being in the interest of Americans, except for vague platitudes about “consumer choice” and “free markets,” as if consumers at the mercy of their local internet monopoly are craving to have their web history quietly sold to marketers and any other third party willing to pay.
The only people who seem to want this are the people who are going to make lots of money from it. (Hint: they work for companies like Comcast, Verizon, and AT&T.) Incidentally, these people and their companies routinely give lots of money to members of Congress.
So here is a list of the lawmakers who voted to betray you, and how much money they received from the telecom industry in their most recent election cycle.
Its an incredible table of data, and I’m always amazed at how cheap it is to purchase votes in congress. This is one of the most egregious uses of lobbying I’ve ever seen, for something that offers no benefit to anyone outside of the telecom industry. Glad to see that the swamp has been so thoroughly drained.
I recently encountered my first need for on-device NDK debugging. While the setup is kind of a pain, its super cool to be able to attach to a remote process over a network socket and have access to the full power of the GNU Debugger. Hopefully this quick guide takes some pain out of the initial setup (root required!).
First, let’s load the ARM64 build of
gdbserveron to the phone. This can be found wherever you’ve placed the Android NDK (in my case, the latest version is hanging out in my downloads folder)
Now let’s jump into the phone, gain root access, and have a look at the PATH. For the sake of convenience, we’ll want to move
gdbserverto somewhere the system is looking for executables.
Looks like there are some options for where to put it.
/system/binare read-only locations, but
/su/binis writable. Let’s move
gdbserverthere and make it executable.
With the debug server in place and executable, let’s check that it can execute.
Great! Now for something more cool. Find the Android Talk process and attach the debugger. The
pscommand lists processes and we’ll use
grepto filter. The second column in the result is the PID of the
com.google.android.talkprocess, let’s start the debug server and attach it to that process.
Now in another terminal from your desktop, we’ll forward the debug ports over the Android USB bridge and try connecting.
The system symbols download and we’re presented with an entry point for the debugger. At this point, you can use GDB in exactly the same way as if you were using it locally or from within an IDE. The Quick Reference is your friend, especially if you’ve spent the last few years in Xcode living the lldb high life.
I spent some time debugging a strange issue today where
outputMediaDataWillChangewas not being consistently called in my
AVPlayerItemOutputPullDelegateimplementation. Without this delegate function behaving properly it is impossible to suspend and resume the
CADisplayLinkdriving our display updates.
On looking at the initial configuration of the
AVPlayerItemOutput, I noticed a race condition:
With the above code it is completely possible (and happens with some frequency) for the
AVPlayerto attempt a call to its video outputs’
This works but it remains pretty strange as you wouldn’t expect the order of operations to matter before the output is added to an
AVPlayerItem. The world is a weird place.
I’ve been having some fun in the last few days blitting video into SceneKit textures. Now going back to
AVPlayerLayerin the same project today, I found an internal SceneKit assertion failing.
Assertion failed: (renderSize.x != 0), function -[SCNRenderContextMetal _setupDescriptor:forPass:isFinalTechnique:], file /BuildRoot/Library/Caches/com.apple.xbs/Sources/SceneKit/SceneKit-332.6/sources/Core3DRuntime/NewRenderer/SCNRenderContextMetal.mm, line 688.
After checking that my SceneKit properties weren’t being used (
sceneViewisn’t even added to the view hierarchy), I changed the initialization of my
SCNViewto use an explicit frame.
Sure enough, using a frame with some pixels in it works. Even if your
SCNViewis not on screen. This would definitely seem to be a SceneKit bug in iOS 9.3 and perhaps going back earlier.
If you’ve tried to run
pod installin the last day or so, you probably found yourself stuck.
Updating spec repo `master`
As discussed by GitHub’s @mhagger, the
CocoaPods/Specsrepository (where all the podspecs are stored) experiences extremely high volume, due in part to shallow initial checkouts of the repository. He leaves a helpful tip to convert the specs repo to a deep checkout.
I tried it, it makes things fast.
This will take a few minutes to run, but
pod update, etc are all much faster now.