Tomorrow Apple will release it's version 10.11 of OSX called "El Capitan".
Although not a whole lot is changing on the outside, there is one big (and often unreported) change that will affect 'power users' like bioinformaticians, and that's the introduction of "System Integrity Protection" or SIP. Although it doesn't remove the root account per se, it will prevent all users (including root) from modifying or writing to system paths and files. These paths include:
/System/bin/sbin/usr(except/usr/local)
Any files not part of Apple's core system will be moved out of these locations, although I'm currently not sure where too (probably /usr/local).
Any hardcoded paths or software you have installed in these system paths will obviously cease to work.
Also, any tools not cryptographically signed by Apple via the AppStore (which is pretty much all bioinformatic software for OSX) will no longer be able to interact in certain low-level ways with the kernel. For example, any scripts you use that make use of DTrace (Apple-made like iosnoop, or 3rd party like the workflow logger I just upgraded to make use of DTrace -_-; ) will no longer work. Apparently this only affects "restricted processes" but from what I've tested this seems to be everything. I have no idea which bioinformatic software, if any, use such low-level interaction with the OSX kernel, but certainly the following applications you might currently be using will no longer work:
- TotalTerminal, TotalFinder and TotalSpaces
- SuperDuper (restored backups will have SIP turned off)
- lldb (popular debugger that ships with OSX now can only attach to non-protected processes)
- A whole bunch of python modules (e.g., lxml)
Also, unrelated to System Integrity Protection, anyone using a non-Apple SSD may remember that Yosemite prevented TRIM support by 3rd party apps. TRIM makes your SSD last a lot longer, and perform about 5x faster. It's now back in El Capitan, as a program called Trimforce, but you have to turn it on manually and accept the waiver that the SSD might become corrupt, although there's a pretty tiny chance that this will happen if its a new TRIM-compatible SSD.
I am hoping that in the next few days we WONT see a huge number of complaints about xyz software no longer working, but to be on the safe-side I suggest sticking to OSX 10.10 until you know your pipeline will work on 10.11 :)
Such effort to ruin a perfectly good OS. Do you know if it's possible to put symlinks in e.g. /bin?
I know right. I think the real reason for all this is to make DRM something achievable going forwards, because before no matter what DRM procedures where in place, you could always dump the memory of a process (like iTunes) after whatever kind of protection is used. We'll know in the future when content can only be downloaded from the AppStore if you have SIP turned on...
As for symlinks, I think its a no :( https://github.com/mitchellh/vagrant-installers/issues/54
lldb comes with the Xcode 7 CLI updates for 10.11 betas, along with other updates to the clang/LLVM toolkit. So I'd be pretty surprised if Apple put efforts into updating it if it isn't ultimately intended for public use. Homebrew (where a good deal of FOSS scientific software comes from) already puts binaries in /usr/local. So unless you're doing something dumb like overwriting system components, then you're probably fine. I have noticed that tools like gdb need code signing, but that can be done easily with a self-signed certificate by anyone with a basic level of skill at the command line. I'll dissent and suggest that, unless you customize OS X a great deal, it is unlikely to have much of a negative impact for bioinformaticists, let alone regular users, and those whom are affected can ultimately disable this by turning off SIP, at the risk of borking their system by doing something they shouldn't.
The problem is that this may just be the start. How long until more and more libraries get restricted. This is a worrisome development.
Thats good to hear Alex - I certainly hope that is the case!
Yes, HomeBrew installs things in /usr/local, but there have been a number of people who after switching have experienced problems, mainly because they are using old versions of Xcode. It seems updating xcode and reinstalling python fixes everything:
http://www.stewright.me/2015/07/homebrew-install-errors-in-osx-el-capitan-heres-a-solution/
http://andinfinity.de/quick-note-homebrew-installed-python-fails-to-import-zlib/
Good news about self-signing, I will definitely try that out! :)
And you're right about lldb, I should have mentioned that it will still work for non-SIP protected apps. It won't be able to attach to system process like Finder, etc, but will still work for most things coming out of the world of Bioinformatics. To quote Apple's website "This will only effect you if your application integrates with the operating system". I agree it wont effect *most* bioinformaticians, but it will affect some - and those that it does effect will be effected hard, with error messages not at all related to the issue (as per the second link). The real problem is the no write access to /bin and /sbin. People frequently make/make install to "/bin" and "/sbin".
Do people really frequently install stuff into /bin and /sbin? That kind of defeats their purpose.
I have personally witnessed some other Bio PhD students at my institute moving binaries to /bin so they get tab completion in the terminal :P And while I laugh about it now, I shouldn't really. That was me more recently than I'd like to admit... in fact if I hadn't started writing my own programs and read up on where my installers *should* move my programs too, I guess I still wouldn't know the difference between /bin, /usr/bin, /usr/local/bin, /usr/local/sbin, etc...
It certainly won't be the end of days as Alex points out, but I would be very surprised if we don't see a fair few issues on Biostars cropping about how xyz used to work and now just doesn't. At least for the next few weeks while things get smoothened out. Unlike the AppStore analogy, this directly effects existing tools, both where they are on disk, and in some cases how they run.
Those it affects, you turn it off and take your chances. We had similar worries about the Mac App Store locking out all other avenues for apps, and that disaster never came to pass. So I don't really see why these are now End Times, either.
To add to some of the discussion here, there is now an ad hoc guide for dealing with SIP with Hombrew on their github site. To be honest, it sure doesn't seem like this change will simply go unnoticed. Particularly worrisome is the "hint" they mention that the protected status of /usr/local will be restored on every update. I'm sure some really smart people will find workarounds, but it makes me a little nervous (about to buy a new laptop) thinking about all the stuff I was able to do in grad school because I could hack away with my Mac (installing genome browsers, databases, graphics libraries, etc. before Homebrew came along). We will still find a way to do all those things but I can see a lot of stuff breaking in the process (at the least, our old way of doing things).