From 9a88e9ff0385f66e7c565a394908503dc6e916ad Mon Sep 17 00:00:00 2001 From: neodarz Date: Fri, 28 Apr 2017 00:30:19 +0200 Subject: Site updated at 2017-04-28T00:29:42+02:00 source branch was at: f1965c50670f611ef54f9471490d45a554f7d866 Correct a link --- .../blog/2015-10-14-sip-for-the-greater-good.html | 43 ++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 build/blog/2015-10-14-sip-for-the-greater-good.html (limited to 'build/blog/2015-10-14-sip-for-the-greater-good.html') diff --git a/build/blog/2015-10-14-sip-for-the-greater-good.html b/build/blog/2015-10-14-sip-for-the-greater-good.html new file mode 100644 index 00000000..18894bcf --- /dev/null +++ b/build/blog/2015-10-14-sip-for-the-greater-good.html @@ -0,0 +1,43 @@ + + + + + + + +SIP — For the Greater Good + + + + + + + + +
This blog has been archived.
Visit my home page at zhimingwang.org.
+ +
+
+

SIP — For the Greater Good

+ +
+

In recent months I wrote a few thousand words lamenting Finder and SIP on El Capitan. See The sad state of Finder on El Capitan and its follow-up.

+

For the record, I'm not blaming SIP. It does deal a serious blow to people who in-memory patch stock applications (and there's a good discussion about the creativity aspect on ATP episode 128), but the general public — at least more than 95% of users — should not be negatively affected, at least not in the short term. And I can understand why SIP protection comes at this time. Macs used to be safe, but in recent years we are seeing real world exploits increasingly more often. History has shown that technically-challenged users simply can't be entrusted with admin accounts, they are too willing to give their passwords to shady software downloaded from shady corners of the web (and sometimes even renowned corners get hacked). But they are given admin accounts anyway (there has to be someone knowing the admin password), so Apple has to come up with ways to protect them. SIP is a pretty good response.

+

SIP is also good for new tinkerers. When I first started to tinker with the command line, I wasn't aware of package managers and I wasn't messing inside virtual machines, so I would download packages from official websites, then manually compile and install them to my daily system. Some packages didn't respect the /usr/local/bin (and include, lib, libexec, share, etc.) convention and insisted on /usr/bin; some others used funny locations like a standalone subdirectory of /usr/local; and when things don't work (e.g., can't find libraries when building — at that time I'm not familiar with CFLAGS=-I yet), I would explictly change PREFIX (probably to /usr) and try again. That way, over a period of a few months, I ended up with a genuinely messed up /usr, with all kinds of stuff everywhere. I probably overwrote quite some binaries shipped with the system. The configuration kind of worked but was pretty fragile. In the end I reinstalled the system, and started to (loosely) follow FHS (Filesystem Hierarchy Standard) and use package managers (first MacPorts, then Homebrew). Good times. If I were to start tinkering today, I would certainly meet some barriers early on, but I would probably also learn the good practices earlier.

+

SIP is clearly the future, and I don't blame it. I just hope we don't see a vulnerability in the implementation soon.

+
+
+ + + -- cgit v1.2.1