Sadly no longer written by John Siracusa, but still a good read: Ars’ Max OS X El Capitan review.
Really, this is the first time in several years that iOS and OS X have felt like they’ve gotten (and needed) the same amount of attention from Apple – both get to spend a release in the slow lane as Apple puts its marketing muscle behind newer platforms like the Apple Watch and the new Apple TV. Like iOS 9 (and Mountain Lion, and Snow Leopard), El Capitan is about refinement. Yosemite’s big statement was “This is what OS X looks like now.” El Capitan’s is a relatively meek “Hey, I have a couple neat tricks to show you.”
To work, both use code injections, one into Finder and the other into the Terminal app, and Apple has blocked this behavior while not providing any API or extensions to more of the system.
The only way to get these apps to work, is to disable a security feature while in recovery mode. Hopefully, the developer will find another way to do them.
Same goes for Total Terminal, he is giving up on it and recommending you use iTerm2.
Edited 2015-09-30 04:21 UTC
Congratulations Apple for the visually ugliest OSX release to date.
Do you really think it’s worse than the old “heavy brushed steel everywhere with added scan lines!” in the 10.1 days?
http://www.guidebookgallery.org/pics/gui/desktop/full/macosx101.png
I actually liked that whole look, muted down a bit more from the original Aqua but still better than the overly flat renditions that now seem to populate modern UIs as some hipster homage to retro looks.
Thoroughly agree. With the exception of the brushed metal, that can be quite tacky at times, I still cherish the look and feel of the earlier iterations of Mac OS X and look with dismay to the current offerings of all vendors, including OSS ones.
Sadly, my beloved KDE is slowly walking on to that direction with Plasma 5 as well…
And to add insult to the injury, GNOME which is known for its – some would say, rather extreme – minimalism, is looking more vibrant and tridimensional than all of the mainstream desktops combined… That’s saying something!
As expected.
Thom, your favorite iOS feature made it to OS X! You can no longer remove Mail and Chess!
Welcome to the age where you don’t own the master keys to your own computer anymore!
Who would have thought it would ever come to that with Apple ? 😉
I’m surprised it took them this long.
What I think is interesting is that it works in a similar way to how Linux user namespaces works (where root in a Linux container might not actually have full root privileges).
If I understand correctly in Windows Administrator doesn’t have all the permissions any more. What was it again Windows Installer has more permissions ?
Edited 2015-09-30 11:03 UTC
Lennie,
More and more we’re seeing OS vendors treating owners like the enemy.
I do see value in sandboxing on most platforms. However it’s extremely disappointing when a vendor designs it to block out the administrator such that the administrator would need to turn it off to access one’s own system. Security features should be designed to empower administrators, not to handcuff us.
It seems to me vendors don’t care much about power users, more about the average users which doesn’t care how the system works.
If we go to the extreme, the average user doesn’t understand software freedom, in the sense of the free software foundation, either.
And it can be argued that the owners bring this on themselves. They simply can’t be trusted with an “open” system. And in the end, that corrupted open system doesn’t just harm the user anymore, but everyone else by fostering botnets and all sorts of other crime enabling behavior.
What would be nice in the next version is more granularity than a simple, huge ON/OFF switch. That way the administrator can selectively open trusted path ways in to their system.
whartung,
I agree, however my gut tells me that apple’s intention is to rope owners out and keep these privileges for itself. For all we know, the next version may disable the on/off switch entirely.
It’s not (only) about treating owners like the enemey. They also are trying to force their “application stores” model down your throats.
Example: recent Windows and OS X versions support sandboxing for store programs only. i.e. if you download a random program for the store, it is fully sandboxed and can barely touch any user files, not to mention system files.
However, if you download a random program from the WWW and run it, it will be run _unconstrained_ in both OS X and Windows. When you need sandboxing most, that is, when you download a random binary from the Internet for a quick thing, current OSes decide its best to do that without the sandbox.
javispedro,
I think you are right on all counts. Sandboxing is extremely valuable for running untrusted apps, ie those downloaded from the web. Unfortunately venders are more interested in making security contingent on their locked down business models rather than enabling all users to benefit from better security.
I would love to encourage the adoption of sandboxes, but not at the expense of freedom. One of my biggest gripes with “metro” is microsoft’s greed. Until I have the absolute freedom to buy/sell/control indy applications outside of Microsoft’s store, I won’t even consider touching that platform. Even if MS reduced their 33% cut to 0%, I’m still totally opposed to them controlling the distribution of my apps, which is tyrannical in and of itself.
Edited 2015-09-30 19:10 UTC
No. The developer decides that, not the OS. If the app was built to be sandboxed it will be, otherwise it won’t be. The OS isn’t deciding anything.
Unfortunately neither OS can sandbox applications that were not built with the intention of running that way, at least not yet.
galvanash,
I’ll concede there can be some major usability problems adding sandboxing after the fact. UAC was a disaster and it didn’t even have fine grained permissions that we’d see on IOS/android. An alternative that may fare better for pre-existing applications that weren’t designed for sandboxing may be an access redirection policy rather than outright denial. Here is 3rd party software that implements this sandbox model.
http://www.sandboxie.com/
True. But I was referring to how things actually are on Windows and OS X, not how they could be. Right now sandboxing is opt in and off by default for “vanilla” binaries on both platforms (metro apps not withstanding). If the app doesn’t opt in to sandboxing it won’t be sandboxed…
ps. I realize that UAC prompts are a form of sandboxing, but Im not counting things that allow interactive control – Im talking about SIP and AppContainer type sandboxing, that is based on trust chains.
Yeah, the OS developers are deciding that. Why is the sandbox availability tied to the Store at all? It would make more sense to disable the Sandbox only for Store programs, for which a revocation process at least exists (but that would be even more tying and annoying, too). And most annoyingly, why is it a developer decision, specially for OS X where sandboxed apps have almost no API changes at all?
A Sandbox that the developer controls is useful for catching bugs, but useless for any actual sandboxing purposes.
Edited 2015-10-01 22:01 UTC
Didn’t say it was perfect, or even good… its frankly a pain in the ass as far as I am concerned… Just saying that is how it works.
You can disable sip, you can then remove the offending apps, and then you can re-enable sip ( or not as you wish ).
Honestly this is how it should work in iOS.
You can’t be seriously suggesting end users need to boot into recovery mode to remove apps.
My comment was a bit of a joke anyway because Thom always complains about the stock iOS apps taking up space on his home screen. We aren’t there with OS X.. yet.
Ironically, this might be a huge boon for crackers. With $1MILLION+ bounties for iOS, some people will be very pleased with the idea that once SIP is cracked, the malware will be almost impossible to remove.
(Is SIP already on iOS?)
Actually if you read those two pages in the review (highly recommended as they are very interesting and full of technical details), you can currently disable the feature by booting into recovery mode.
The scary part is that it only really takes two minor changes from Apple to completely lock down OS X: 1) restrict bootloader, 2) remove that you can disable it in recovery mode.
I don’t know if iOS has SIP installed, but here it doesn’t matter as much since there’s no way to execute a ‘sudo’ without jailbreaking it first.
I have read the whole thing and those two pages are by far the best thing about it
Sorry wasn’t sure if you had or not. Yes, by far the most interesting part.
Ars Technica also reports on a drop dead simple exploit that bypasses Gatekeeper:
http://arstechnica.co.uk/security/2015/09/drop-dead-simple-exploit-…
So young Thomas, are we at this dystopian vision that you had almost 5 years ago when you claimed that Apple would turned OS X into a walled garden? or once again are we going to hear you talk about how it is ‘one more release away’?
Well, with features like SIP and Gatekeeper We are 1-click away from the walled garden, it’s just an on/off switch. I mean, all the “infrastructure” predicted by Thom is there, he was (kind of) right.