This is a mind-boggling level of FUD. Content blockers have been noticeably superior on both macOS and iOS for years. They’re not “limited”, they’re rational. It’s abjectly absurd that traditional ad blockers can consume as much CPU as they do on every single page load. I hope everyone in this thread jumping ship to Firefox in a panic enjoys their shorter battery life.

Disagreed. Content blockers are "dumb" as they just provide a list of URLs/regexes to block, which doesn't always work and doesn't allow behaviour-based blocking like "dynamic filtering" that some Javascript-based adblockers have.

Sure, it's technically possible for a JS blocker to use more CPU, but 1) it's a trade-off the user should be allowed to make (I'm happy to sacrifice some CPU in exchange for better ad blocking and privacy) and 2) I never had a case where a JS-based blocker noticeably impacted performance.

Users should have the choice as to what method of adlbocking they want to use.

Aside from battery life, how are the current alternatives for Safari better than uBlock?

"I hope everyone in this thread jumping ship to Firefox in a panic enjoys their shorter battery life."

10 hours on my Chromebook using FireFox Focus and uBO vs 7 hours using Chrome.

Whatchoo talkin' 'bout, Willis?

And then maintained it and fostered its growth while it became the foundation of modern computing…?

Maintaining and growing an existing tool with its existing developers who you bought in is a good thing and to be applauded, but doesn't necessarily mean the company is good at tooling in general. The cultural requirements are very different.

Some people are really scared of Apple being cool.

I think it's gotta come from the other direction, ultimately. They're working hard to push AppKit forward and bring it into the future, but I think UIKit will figure out the hard problems (menuing, keyboard navigation, pointer input) before that.

I think pointing at Microsoft as having the solution to this problem is disingenuous. Modern Windows has had so many false starts, and I still feel their multi-modal devices are inherently compromised — jack of all trades, master of none.

"Native" being a really relative word here.

[Really easy to enable.](http://internals.exposed/blog/dtrace-vs-sip.html)

But, hey, sure. Don't let that stop you from getting angry. Merry Christmas.

There should be a bingo card for this thread. "#doomed" "taking away freedoms". Free space is "What Steve would've done".

TFA addressed that. For the regular folk, this will be fine. For security researchers, it's a big flag that will let malware change its behavior.

He also posted a handy screenshot that shows Dtrace not working on some binaries even with SIP completely off.

SIP is turned on in the screenshot.

> System Integrity Protection status: enabled.

Ack, you're correct. SIP is on, but everything is disabled.

It seems like they do that on OS X as well.

Based on the warnings in the Console log back when I used Dropbox, Dropbox isn't using fsevents API appropriately but is instead reading from the raw fsevents firehose.

I have nothing to say about your other issues (I haven't experienced most of them; I'm quite happy with the service), but the banner at the top of the More (…) menu takes you to the album of a song, which then easily leads to the Artist page. Do it all the time, takes me half a second.

Forget the "-ish". Actually, forget the "native". Their app is no more or less native than Rdio's was.

Not anymore; those methods are implemented in an extension on `String` that don't always involve bridging back.

They're still only available if you import Foundation. They're just NSString methods with wrappers. The real problem is just that Swift itself doesn't have methods for locating a string in another string, or replacing strings in another string.

This is why I was careful to say that Swift's API is the best in terms of its fundamental design. It still has a lot of missing functionality compared to other languages right now.