I compile a tool we use, send it to another developer, they can't open it without going through system settings because the OS thinks it's unsafe. There is no blanket easy way to disable this behaviour.
We also inject custom dlibs into clang during compilation and starting with Tahoe that started to fail - we discovered that it's because of SIP(system integrity protection). We reached out to apple, got the answer that "we will not discuss any functionality related to operation of SIP". Great. So now we either have to disable SIP on every development machine(which IT is very unhappy about) or re-sign the clang executable with our own dev key so that the OS leaves us alone.
If it's being sent to another developer then asking them to run xattr -rd com.apple.quarantine on the file so they can run it doesn't seem insurmountable. I agree that it's a non-starter to ask marketing or sales to do that, but developers can manage. Having to sign and then upload the binary to Apple to notarize is also annoying but you put it in a script and go about your day.
If SIP is kicking in, it sounds like you're using the clang that comes with Apple's developer tools. Does this same issue occur with clang sourced from homebrew, or from LLVM's own binary releases?
Yes, it kicks in even with non apple supplied clang(most notably, with the clang supplied as part of the Android toolchain, since we sometimes build Android on MacOS and having to re-sign the google-supplied clang with our own certificate is now a regular thing every time there is an update released).
Because...it's official behaviour that is fully supported by clang? If you want to add a hook on compilation start, it's literally the documented way - you include your own dlib with necessary overrides and then you can call your own methods at each compilation step. Not even sure how you'd do it with a shell script? You need to have knowledge of all the compilation and linking units, which....you have from within Clang.
The privacy angle here is wrong, or at least incomplete.
The reason for that is that your ISP is most likely capturing all your unencrypted DNS traffic (port 53) to build that exact profile of you.
And unlike CloudFLare or Google, your ISP, which often is also the company from which you get your mobile phone subscriptions, now knows where you live, who you are, what your family looks like and which specific websites you visit.
Cable/Fiber modem manufacturers are also known to do exactly this kind of data collection. There was a recent example of this where it happened with firmware directly on the cable modem for a Dutch provider.
Running your own DNS server does not change this at all. From a network perspective this is the same: unencrypted DNS that anyone in the middle can see and record.
The only way to work around companies upstream from you is actually to use a DNS forwarder combined with some form of DNS privacy (encryption). A very good way is to have a local DNS Server that forwards to a outside trusted DNS server over DoT or DoH. Both of which are encrypted. Your ISP can see the traffic, but they can't see inside it and find out what DNS queries you do.
That means your devices on your local network can just talk "plain" DNS port 53 like they always do, to your self hosted DNS server. But your self hosted DNS server will then forward those queries to a trusted server _outside of your and the ISP network_ over an encrypted channel.
Note that I do not trust my ISP (Bell Canada) but I do feel ok with using Google and CloudFlare. That is my personal choice and not a recommendation. You can probably find better options - they do need to support DoT or DoH though.
People comparing Docker and Jails don't really understand that Docker is 99% about packaging and composing software. From that perspective Jails are nothing like Docker containers. No versioning, no standard, no registry, no compose, no healthchcks, no tree of containers, etc. etc. etc.
If you want to compare Jails to something on Linux then I think LXD is probably much closer to what Jails are.
RAM Doubler was a third-party application in the days when a top-of-the-line Mac had 128MB of RAM, with a 40Mhz processor. The level 2 cache was 256 bytes.
That's not in the same universe as hardware compression on a 6-core, 64-bit ARM processor with cores that can run at 4GHz.
Weird .. I easily run 40 docker containers on an 8GB MacBook just fine!
(Just posting this to show that you have to be very specific when talking about these kind of things. Yeah maybe you need 32GB because you run some large deployment 3 times. Others mayb be totally fine with less if they just develop a basic Python web app. Who knows. The devil is in the details. Omitting them makes the discussion ambiguous and just difficult.)
reply