This is the bit I think might potentially cause confusion and this that approach might be better in a spin off
Valid point. They only just very recently updated "Automatic" to potentially make it stop setting unwanted hackintosh stuff.
From what I've just been told and read, I think it is more a documentation thing. If you need it on some earlier machines, and on Catalina, then it seems absolutely fine that it is on by default, if there's also a clear message that, if you are using hybridization and if you have the bios number faked and if you find you are getting updates anyway without it (which is likely to be true on newer machines, and/or once you've got past Bug Sur 11.1) then you no longer need it.
If you leave it ON the power management does not work. So it is not a good idea to stay permanently.
Yes, I can, everything I said can easily be translated to the config here, and works just the same. I think, for convenience, that I'll do that (obviously testing it, to make sure I'm right) in future.
Maybe you can consider this also:
I agree but the Apple
plistlib library formats this way the code. For the sake of easiness of comparing the code, I think is worth the adjustment.
I AM NOT DOING FULL SN SPOOFING! 🤪 I've actually be arguing against it. Even if I avoid talking in Automatic=true terms in future on here, for convenience of communication(!), I still assure you that using Automatic = true is 100% is not equivalent to doing full SN spoofing (you can do full SN spoofing, or not, with Automatic = true, or not): see here for a discussion about doing it, or not, with Automatic = true. And also OpenCoreAPFSLoader (widely used on the other thread, for a while) always used Automatic = true and (I 100% promise you!) was not a full SN spoofing approach.
I think @startergo was just emphasizing that point which we all agree on. Don't worry about not mentioning Automatic=true. Acidanthera's receptiveness to the issues you've raised have made automatic mode a possibility for effective hybridization. In fact, we should explore the new possibilities with OC as they arise.
Unfortunately too many people will use too many different tools (each with their own advantages), I think, and OC itself is tied to using Xcode as its plist tool, I'm sure! Here, I found the ref in
Configuration.pdf:I've just now double-checked this, because obviously it matters, and Xcode does produce
<array/> and <dict/> output for empty elements.
@TECK I appreciate you're doing a lot of work for the benefit of others, working on this thread particularly, and for some time! So all other things being equal, of course you get to choose the preferred tools and not me! But the format which (admittedly) I've got used to seeing is the format the OC project themselves use, and recommend. For that reason (only!) I don't think the choice of tools, if made to give greatest ease of use to everybody who comes to the project, and wants to link what they learn with the greater OC world, is a free choice. :-/
plistlib the Python library I'm finding? Did you mean plutil? I've got myself slightly confused about that, but I don't think it affects the above... (I hope!).
Working perfect for me to unlock with watch, see signature what BT card I use.
There is only one official library to programatically build macOS .plist files, the plistlib library (not plutil) which is part of the OS. I honestly think we are nitpicking now. On my side, I will continue to use the format plistlib generates, for simplicity reasons. What is important for me is to get a configuration that passes the ocvalidate check.
In that case, the library should be able to easily convert to the short syntax, which Xcode and plutil use. Using the short syntax is the right choice: it is used by the Acidanthera documentation and samples.
plutil does not convert empty elements to escaped elements. The fact is using <array></array> will not flag any syntax warnings or errors in any code validator. BTW, is very easy to fix that programatically with Python, but I prefer to keep whatever the Apple developers designed to produce with that library, as end-code. If Xcode produces <array/>, then eventually plistlib will have that addressed also and the issue will be corrected automatically.
Yes it does (although not automatically): try
plutil -convert xml1 file.plist
It is 100% not a syntax error, absolutely 100% agreed. But I've also just checked that too, and
plutil -convert xml1 config.plist 100% does convert <dict></dict> and <array></array> to <dict/> and <array/>. (At least on my Mac, with my unmodified - AFAIK - version.)
I presume it keeps
<string></string> even though <string/> is apparently valid (I think).
ocvalidate checks, I also saw this was being discussed and wanted to offer some quick, recent info. @TECK I think we are in agreement about this one - and probably not really in any disagreement about plist libraries, either, so sorry!DataHub, Memory, PlatformNVRAM and SMBIOS sections can be validly completely omitted if they are not being used. (Apparently this was always true, just not completely clearly documented.)SMBIOS out of the above, the other three can just be removed, removing tons of errors.Generic apparently should never be omitted, and still needs filling out, but that is many less errors than currently.Generic wrong, fixed. - potentially be an argument to move to using the Automatic=true method of weak, hybrid faking? (But, to be clear, I am 100% not, ever, advocating strong, full-serial faking on a legacy Mac!)
TECK - did you have to do any patching in Big Sur? I patched both Mojave and Catalina to enable Continuity/Apple Watch unlock but poking in Big Sur shows Continuity disabled for my MacPro5,1. I'll have to open my machine to see what Broadcom card I have though it works for Bluetooth and WiFi fine in Big Sur.