Please, don't forget that you talk to a real OSS expert here,
someone with many years on his resume so trust me;
I've learned not to trust but proofs and my own experience and research, in our case it's a very simple subject
the Chameleon project is violating the Apple license (just read the license) and once you tag it with that license, there is no way back.
We would be glad to be proven wrong, and we'll fix our mistakes. And so, we are either blind or we didn't understand the license, maybe you can point out the exact thing that Chameleon is violating by quoting from the APSL?
Oh but don't get me wrong, that would be nice. Of course, but it should be a separate project. Not included with the booter.
Which leaves a second option (or maybe the first); in KEXTs. But also don't get me wrong here, my main motivation here is to highlight that things are done not in their intended and best place; the DSDT is very specific to the HW, and the way people are modifying it is hard-coding values and adding methods they don't even know what they are for, sometimes unnecessary, and that is still nothing close to a real solution and is far from being automated.
I've done this, and I'm probably the first person who did it for OSX and release the fixes, but I knew it could be done better,and I did find better automated ways which save me time and effort, obviously, I'm using them.
I want to note that we work on complete solutions, the booter is just a part (an important one).
Yes I do, and that is why you use certain features in your browser that were introduced by me, simply because I think different
I'm a FireFox user because I have use for it, thanks for your work
Again, I just don't think that a booter fits this part of the project. But feel free to convince me otherwise.
The solutions you talked about are not user-friendly, not automated, limited, and have serious issues in the case of the DSDT (both the DSDT modifications and the device-properties need support in the booter
An EFI-based booter (calling it DUET-based is probably more accurate) is "fat" and people have use for just like they do have use for "the fat" Chameleon. The EFI environment is almost a tiny OS, and I'm very fine with that.
But of course, but with a real Open Source project you can take over, fix things yourself, but that won't work when people hold back with source code, basically violating the Apple license.
I'm not an Open Source purist, I think it doesn't work for all projects; there are closed projects/apps that are more succeful then their Open Source alternatives. And closed worked and still works for many; M$ , Apple, Games.. etc.
But again, I prefer OSS for the reasons you mentioned.
Note that we have released the sources for previous versions of Chameleon, and we talked about v2 in our site if anyone wants to check.
A single leak can prevent shutdown and/or restart from working, and ChameleonSM isn't clean so guess what. I got to freaking fix it simply because I cannot shutdown when I use it.
Isn't that the case of every (Open Source/) software?
The reboot/shutdown issues are in most cases OS issues; in your case it's not because of issues in ChameleonSM (why would an OS depend on SMBIOS data for reboot/shutdown?) but because of the assumptions OS X makes and the way Apple made it. Mac
OS X is written for Macs, for that specific HW.
Answer this: "Why do people need Chameleon?"
and "What problems do they face when they use it?"
We have bug reports and we try to fix them, it's just about time, will and motivation.
and you know what I mean. Or not of course
I'm going to guess the DUET-based booter doesn't have the issues Chameleon have? That doesn't mean DUET doesn't have issues, and it doesn't mean issues can't be fixed (for both).
The only DUET-based booter known till now (at least for me) is iPhoneTom's (we both discuess about (U)EFI/edk(2) stuff) XPC, and that is closed source (so far).
Note: I left the obvious remarks unanswered – I have more work to do.
Good luck with your work