Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Apple Releases Second OS X 10.11.4 El Capitan Beta to Public Beta Testers
- Thread starter MacRumors
- Start date
- Sort by reaction score
Oh, f...
Do you know why are there problems in 10.11.4 publiuc beta 2??
Till now I only saw your issue with Wifi, hm...
maybe it's just sth on your Mac??
Whats was the quickest way to get back to beta 1?
I don't like to restore to 10.9 than 10.11 and 10.11.4 beta 1
Do you know why are there problems in 10.11.4 publiuc beta 2??
Till now I only saw your issue with Wifi, hm...
maybe it's just sth on your Mac??
Whats was the quickest way to get back to beta 1?
I don't like to restore to 10.9 than 10.11 and 10.11.4 beta 1
For me I:
1) saved all changed files to a SD card
2) restored 1st beta from a Time Machine drive (I didn't backup for six days, my bad, hence step 1)
3) restored the files from SD card
Right now I am backing up again and going to do another install of beta 2 and see what happens to wifi. Maybe it was a glitch of some sort. I am definitely no longer used to the constant wifi dropouts. I'll keep you updated.
1) saved all changed files to a SD card
2) restored 1st beta from a Time Machine drive (I didn't backup for six days, my bad, hence step 1)
3) restored the files from SD card
Right now I am backing up again and going to do another install of beta 2 and see what happens to wifi. Maybe it was a glitch of some sort. I am definitely no longer used to the constant wifi dropouts. I'll keep you updated.
Given how long the sudo exploit bug was out in the wild, you probably wouldn't hear about it. That's why you need SIP.
This?
I am not an expert by any means so it's good to actually learn something. My most useful contribution here is "I never had this problem". Thanks for answering my questions
So SIP would actively prevent against this type of exploit happening?
XtraFinder dev suggests using
It allows cDock to work as well. Is it putting the user (i.e. me ) in danger of the sudo exploit bug?
Meanwhile, in the on topic bit, I installed the second beta again and wifi hasn't crashed for three minutes yet but I promise not to livetweet this
I am not an expert by any means so it's good to actually learn something. My most useful contribution here is "I never had this problem". Thanks for answering my questions
So SIP would actively prevent against this type of exploit happening?XtraFinder dev suggests using
Code:
csrutil enable --without debugIt allows cDock to work as well. Is it putting the user (i.e. me
) in danger of the sudo exploit bug?Meanwhile, in the on topic bit, I installed the second beta again and wifi hasn't crashed for three minutes yet but I promise not to livetweet this
I have recently reported 3 uncommon issues to Apple via Dev bug reporting site. They have emailed me in all 3 cases for one reason or another as a follow up. Even one that crossed over into an issue with Logic Pro X. I was quite surprised.
Thanks!
I'm giving it a try. I rebooted the MBP 2x. Till now couldnt see any glitches.
Would be nice if you update us with your update experience.
Last edited:
My old Wacom Bamboo (MTE-450) tablet and its Control Panel is now working properly again with this new beta!
There is an easy fix for that: Go to System Preferences -> General -> Show scroll bars and check When scrolling. That's it.
Last edited:
SIP is an inelegant solution to a pretty difficult problem to solve. The primary issue with SIP is that it implements a protection mechanism but then doesn't also implement a user-driven work-around mechanism. Let me explain that, lest someone less technically competent attempts to "explain" it away: SIP uses code-signing, cryptography, to "vet" code and restricts otherwise what can be modified by the "root" user. That's great. That is helpful, VERY helpful. HOWEVER, and this is the mess: they didn't also implement some form of local user override! If I have an older kernel kext (say a Cisco VPN kext or a PCI card driver) that I –explicitly– want to allow to run, OS X should –ALLOW– me to sign that kext locally and communicate to SIP to make an exception ONLY FOR IT. Crypto ALLOWS for this, simply APPLE didn't. Why? Because they want to push developers to do what Apple wants. Unfortunately, thats not always convenient for users with investments and work to get done. CERTAINLY by providing an avenue to even singly bypass SIP you're creating a security risk…but significantly less than by disabling SIP entirely. Sheesh, Apple could even say "Hey, you get a dev account, run all these command line commands, submit the output to an Apple webpage and wait for an email back…", something REALLY consuming…just give me the override opportunity! It would be better than what I have today.
As to WHY the problem is difficult…well, that's another story. The entirety of the UNIX permissions model is kinda fundamentally broken. I just is NOT a good way to go by starting out as GOD, and then dropping down. There have been many attempts to CORRECT this, GNU Hurd is working on one, Microsoft is also working on it in Windows. But it is HARD to undo decades of done. In short, the idea that "sudo" to "root" exists and is used is pretty bad. Admin privs in OS X should NOT be providing "root" access, it should only be switching to a higher authority. 99.94% of all NEED for Admin privs is merely to install software (and a LOT of those cases should probably NOT require Admin privs). If Apple had been smarter from the START with engineering their Installer tech, they'd not done what they did. Linux learned really early how big a mistake it was, and most packaging tools runs as a system user with constrained privs, not as root. Apple had all the "lesson" they needed to learn from the Installer tools in classic Mac OS; the team that worked on OS X threw all that "knowledge" out and thereby failed to learn the valuable lessons from it. The Windows team, however, was forced by Malware to learn them, a VERY hard lesson. Now…NONE of this applies to command-line BSD, but how many people USE OS X for that? Apple has not yet brought OS X to feature parity with what Linux has been doing for nearly a decade, and for that, Apple should be looked at sideways. OS X is going on 20 years old (not including the NeXT lineage); to say that it is a stagnant system when compared to the competition, technologically, is not an overstatement.
Long and short, SIP should really be looked at as a stop-gap. It does what it does, it SHOULD be there and it SHOULD BE enabled, but it isn't an elegant solution to the bigger problem.
As to WHY the problem is difficult…well, that's another story. The entirety of the UNIX permissions model is kinda fundamentally broken. I just is NOT a good way to go by starting out as GOD, and then dropping down. There have been many attempts to CORRECT this, GNU Hurd is working on one, Microsoft is also working on it in Windows. But it is HARD to undo decades of done. In short, the idea that "sudo" to "root" exists and is used is pretty bad. Admin privs in OS X should NOT be providing "root" access, it should only be switching to a higher authority. 99.94% of all NEED for Admin privs is merely to install software (and a LOT of those cases should probably NOT require Admin privs). If Apple had been smarter from the START with engineering their Installer tech, they'd not done what they did. Linux learned really early how big a mistake it was, and most packaging tools runs as a system user with constrained privs, not as root. Apple had all the "lesson" they needed to learn from the Installer tools in classic Mac OS; the team that worked on OS X threw all that "knowledge" out and thereby failed to learn the valuable lessons from it. The Windows team, however, was forced by Malware to learn them, a VERY hard lesson. Now…NONE of this applies to command-line BSD, but how many people USE OS X for that? Apple has not yet brought OS X to feature parity with what Linux has been doing for nearly a decade, and for that, Apple should be looked at sideways. OS X is going on 20 years old (not including the NeXT lineage); to say that it is a stagnant system when compared to the competition, technologically, is not an overstatement.
Long and short, SIP should really be looked at as a stop-gap. It does what it does, it SHOULD be there and it SHOULD BE enabled, but it isn't an elegant solution to the bigger problem.