AnV Chameleon boot loader

[justvisiting]

some of you guys'n'gals are so funny, so quick to turn on each other, incissors and knives ready for attack thank you for all the entertainment, so much drama and angst and childish behavior -- its cheaper than a night at the movies.

 

"...andy and his followers..." ahahaha now its religious ideology && warfare!! thank you!! very amusing.

 

for those that do the work and share the work without the ego -- thank you!

[Sengo]

Sorry to say , but you are a drama queen PolishOX !

 

Wonder why there is so much hate in this thread , Andy fixed problems with the code in chameleon and instead of people being happy and enjoy his work it's all about omg he's ripping of chameleon's team work etc etc ...

 

Pff ... hopefully the chameleon team will take his improvements and make use of it (if they didn't fix it before) , been waiting for the new release but i totally dislike your approach on this matter PolishOX .

[zef]

Sorry to say , but you are a drama queen PolishOX !

 

Wonder why there is so much hate in this thread , Andy fixed problems with the code in chameleon and instead of people being happy and enjoy his work it's all about omg he's ripping of chameleon's team work etc etc ...

 

Pff ... hopefully the chameleon team will take his improvements and make use of it (if they didn't fix it before) , been waiting for the new release but i totally dislike your approach on this matter PolishOX .

 

There's no hate here, just pretty please compare the sources and tell me what are the improvements (besides mackerintel's already published DSDT fix). Sorry to say, but AnV's current fixes are ends up eliminating some compile time warning messages. Or am i missed something else?

[Guest BuildSmart]

Most people don't have the vision to see that forking of projects in the long term is a bad thing. The chameleon project is extremely active and has a number of developer contributing nearly daily to the sources. Taking Chameleon to the next level has required massive internal restructuring and just breaking the 64k limit was a difficult and long process. The chameleon project now is part of the Voodoo team and other than the kernel work there are a number of other projects in development.

 

The long term goal is to create quality alternative implementations of the key foundations of OS X. This was why the kernel was dealt with first and the boot loader is in the process of being made much more modern and expandable. We also have a few other extensions that will resolve some very outstanding and troublesome issues for users. Also some of the smaller extensions which have been required have become integrated into the boot loader (SMBIOS enablers, EHCI ownership problems etc). We also hope to have PCI probing added to allow device properties to be added (to fix problems such as GMA 950 on some systems as well as networking problems - time machine).

 

While the source code for all these projects will be open to everyone, during development we have found that its better to keep the sources closed. The truth of the matter is that most people have no interest in enhancing and fixing problems with OS X. The kernel sources we put together have had practically no interest (and even with a simple building tool to make kernel compiling easy for those looking to learn). The majority of the advancements in OS X running on normal PCs has been done by a very small group of people. I wish I could say it was a community achievement but that really hasn't been the case at all.

 

While its possible for the community to continue to toss out DVD's with a million different options (just look at the new iPC DVD) practically no user will know what option to choose and end up with a system that doesn't work. Is this the direction we really want to go? Alternative extensions with a quality boot loader and kernel will give a much simpler install and a much higher compatibility. If the OS X community wants to grow up, it has to move in this direction. This is what the Voodoo team is trying to do. We hope others are willing to join us.

Forking???? I don't consider this work a fork.

 

When newer binaries for chameleon are released and the source is not available it makes it hard to fix any issues that the binaries produce, the code that is available doesn't build cleanly and has far too much of the released functionality missing and adding flags to disable items that supply information is the incorrect approach forcing the bloating of the com.apple.Boot.plist.

 

Hard coding of any information is a step backwards, if you wish to do it in such a way allowing the user to decide what information is needed to be coded and the information that is coded is definable it is a good concept otherwise using the binaries becomes more troublesome than they are worth forcing the removal and rebuilding of the binaries which is not possible when the source is not available.

 

Since the project is GNU-GPL the source and patches for the released binaries should be available and the lack of them means the binaries aren't useable when their current configuration prevents use due to conflicts.

 

While I think the chameleon project has contributed to the movement it also hinders use and development when a select few have access to the current source preventing anyone else not part of the chameleon group to work with the current source.

 

What I do know, the latest chameleon does not work with my dynamic GUI boot loader so waiting for the source to be released so I can fix it has been a long waiting process.

[SticMAC™]

Will run this on my wife's Aspire ONE 150, let you know.......

<afrikaans>Dankie jou werk is altyd van die hoogste gehalte! </afrikaans>

 

SticMAC

 

<dutch>Geen probleem, graag gedaan, de Belgen helpen ook graag mee </dutch>

[Guest BuildSmart]

I'm wondering about the technical details how AnV's code-base can be a "far better" one?

While there's no question about dfe's achievments regarding the fake EFI implementation and his overall professional developer kind, but your above statement ignores about 3 months of work in all stages in in the boot loader project. How about hybrid GPT/MBR aware boot0? How about the HFS file system loader code found in boot1h? How about Kabyl's proper fsb detection/cpu support? How about foreign OS support for GPT disks? These are all unique developments what you can't find in any other implementations.

Yes zef, I acknowledge you have made improvements, not meant to insult you, I recommend chameleon to people with non Intel motherboards who want/need it due to DMI programming issues and that is as far as it goes.

 

Breaking the 64k barrier has advantages for some but I have yet to find the need to use a boot loader file larger than 64k that provides features and functionalities hard-coded that are not required or needed.

 

Using the boot file actively (embedded in partition) or passively (placed at drive root) is a matter of choice and advantages to each method exists and is outside the scope of this communication.

 

While the current available chameleon source is useable in most cases, examination of the code shows that several people contributed and some areas of modification could use some cleaning up and/or rewriting due to variances in programming habits.

 

So it is your opinion that warnings based on cast bares no performance loss but I think you might find that this opinion is not held by everyone with programming knowledge/experience.

 

My reasoning for liking Andy's code-base is, first and foremost, the current source is available, second, it builds cleanly and it does not interfere with configurations that provide proper DMI data (once you remove the hard-coded cruft), has pretty much everything needed except for the /Extra loading stuff, doesn't have any issues loading on a BadAxe2 like chameleon does (unless you have the updated chameleon boot0/boot1h files).

 

If you want to add all kinds of bells and whistles that provide DMI data that's nice but hard-coding causes problems and removes flexibility.

 

Coding DMI for a MacPro is hilarious to say the least since the majority of users have C2D or C2Q CPU's and hardware that requires so much file patching that even matching the iMac hardware is so far out in left field and running vanilla is impossible.

 

If you really want to hard-code DMI data then add a flag to enable the feature rather than forcing the data, the flag should enable the data, using a flag to disable data makes little sense and if you want to hard-code data why not code "Apple Developer Platform" or is the "MacPro" label that important to the chameleon project that it has to mess things up for people that don't need it.

 

Now I see references to VooDoo and chameleon getting into bed together, this sounds like a bad idea and will only breed bias in concepts and directions.

 

VooDoo is OK for people with older Intel (non-Core) and AMD CPU's but it certainly has little it can offer me.

 

The direction of chameleon should be a push towards a more vanilla installation, if you want to add functionality then make loadable modules stored at a specific path and refrain from bloating the main binary.

[Kabyl]

Forking???? I don't consider this work a fork.

 

When newer binaries for chameleon are released and the source is not available it makes it hard to fix any issues that the binaries produce, the code that is available doesn't build cleanly and has far too much of the released functionality missing and adding flags to disable items that supply information is the incorrect approach forcing the bloating of the com.apple.Boot.plist.

There are no binaries of Chameleon with unreleased sources, last version till now is 1.0.11 and the sources are available for everyone to play with.

Hard coding of any information is a step backwards, if you wish to do it in such a way allowing the user to decide what information is needed to be coded and the information that is coded is definable it is a good concept otherwise using the binaries becomes more troublesome than they are worth forcing the removal and rebuilding of the binaries which is not possible when the source is not available.

 

Since the project is GNU-GPL the source and patches for the released binaries should be available and the lack of them means the binaries aren't useable when their current configuration prevents use due to conflicts.

Chameleon is not under the GNU-GPL, it's APSL.

and again all official Chameleon released binaries have their sources released at the same time.

While I think the chameleon project has contributed to the movement it also hinders use and development when a select few have access to the current source preventing anyone else not part of the chameleon group to work with the current source.

This is something we have decided to do, and we think it's working fine. We are under no obligation to make the internal sources available to the public.

It's clear that we are not (and can't) prevent anyone from working with the currently released sources.

What I do know, the latest chameleon does not work with my dynamic GUI boot loader so waiting for the source to be released so I can fix it has been a long waiting process.

Sorry for making you (and probably many others) wait this long, we have other things to do.

As of your dynamic GUI boot loader, why don't you release the sources so someone will fix it for you, or try to ask for help?

 

Yes zef, I acknowledge you have made improvements, not meant to insult you, I recommend chameleon to people with non Intel motherboards who want/need it due to DMI programming issues and that is as far as it goes.

 

Breaking the 64k barrier has advantages for some but I have yet to find the need to use a boot loader file larger than 64k that provides features and functionalities hard-coded that are not required or needed.

That's an opinion, others found it "very" useful.

Using the boot file actively (embedded in partition) or passively (placed at drive root) is a matter of choice and advantages to each method exists and is outside the scope of this communication.

 

While the current available chameleon source is useable in most cases, examination of the code shows that several people contributed and some areas of modification could use some cleaning up and/or rewriting due to variances in programming habits.

Yes, and we're trying to fix as much as we can. I think it's enough that people release and share their stuff.

So it is your opinion that warnings based on cast bares no performance loss but I think you might find that this opinion is not held by everyone with programming knowledge/experience.

Good to know that!

My reasoning for liking Andy's code-base is, first and foremost, the current source is available, second, it builds cleanly and it does not interfere with configurations that provide proper DMI data (once you remove the hard-coded cruft), has pretty much everything needed except for the /Extra loading stuff, doesn't have any issues loading on a BadAxe2 like chameleon does (unless you have the updated chameleon boot0/boot1h files).

it doesn't have issues loading on XBX2 because you're probably using it as a startupfile, and last time I checked we still didn't fix that in boot0/boot1h, but that's something for zef to confirm.

If you want to add all kinds of bells and whistles that provide DMI data that's nice but hard-coding causes problems and removes flexibility.

 

Coding DMI for a MacPro is hilarious to say the least since the majority of users have C2D or C2Q CPU's and hardware that requires so much file patching that even matching the iMac hardware is so far out in left field and running vanilla is impossible.

 

If you really want to hard-code DMI data then add a flag to enable the feature rather than forcing the data, the flag should enable the data, using a flag to disable data makes little sense and if you want to hard-code data why not code "Apple Developer Platform" or is the "MacPro" label that important to the chameleon project that it has to mess things up for people that don't need it.

Some people might find it useful still, it's true that is hard-coding, and I personally don't like that route.

If you have done some work on this don't mind sharing.

Now I see references to VooDoo and chameleon getting into bed together, this sounds like a bad idea and will only breed bias in concepts and directions.

that didn't make any sense, I expect a technical explanation!

VooDoo is OK for people with older Intel (non-Core) and AMD CPU's but it certainly has little it can offer me.

If you did read about it, it has things to offer even for those who are able to run the vanilla kernel.

I don't think voodoo is OK, I think it's GREAT.

IF it doesn't offer you any benefits, you should just keep using your current preferred kernel.

The direction of chameleon should be a push towards a more vanilla installation, if you want to add functionality then make loadable modules stored at a specific path and refrain from bloating the main binary.

Thanks for all your suggestions, now it's up to us to decide what to do with "our" project. We do listen to all suggestions, but don't expect everything to be implemented.

 

Since we're not (and can't) prevent anyone from improving/adding features/fixing/*whatever* the current released Chameleon, you can start working/applying whatever suits your needs, and what you see is the right thing to do.

 

-Kabyl

[Guest BuildSmart]

Zef personally gave me a set of binaries that have the badaxe2 issue resolved, these same binaries and newer are being used in distros and works so it's hard to claim that newer work isn't being used when it can be found.

[mitch_de]

Hi, chameleon PROs + master developers here in discussion

It would be great if you update your homepage sometimes with news of your work.

http://chameleon.os???.hu/

I would like to get more involed ( as end user) about the ideas+programming problems (you have to master).

Its one of the main OSX86 homepages which has the oldest / unupdated informations for end users.

Thanks for great chameleon dev work, but please give some of your small time also for updating your hompage with ch news,

[justvisiting]

There are no binaries of Chameleon with unreleased sources, last version till now is 1.0.11 and the sources are available for everyone to play with.

 

...

 

Thanks for all your suggestions, now it's up to us to decide what to do with "our" project. We do listen to all suggestions, but don't expect everything to be implemented.

 

Since we're not (and can't) prevent anyone from improving/adding features/fixing/*whatever* the current released Chameleon, you can start working/applying whatever suits your needs, and what you see is the right thing to do.

 

-Kabyl

 

Hello Kabyl,

 

Thank you for your reply.

 

As you said, it _IS_ "your groups" project and there are benefits to a closed development cycle followed by src code release.

 

One question to ask: Is having the chameleon source code repository available for read-only access during the development cycle of greater benefit than the closed model?

 

I would say yes --

 

1) it synchronizes other "projects" that build on on chameleon, allowing them to release faster.

 

2) it provides other developers experiences with the "growing pains" within a development cycle -- when you have a problem and its resolution history is detailed, others can learn from that.

 

3) most importantly, grows the "software based ecosystem" based on chameleon.

 

 

thanks for the discussion and the hard work.

[Guest BuildSmart]

The GUI boot selector is waiting for an efi boot loader to boot OSX, when the project is in end-user form then a release and source will be available as complete packages, it's not broken, just incomplete.

 

Releasing code that is incomplete makes no sense unless the project is being abandoned which it isn't, it might be easier since you guys have released binaries without source to forego the GUI and make what I have work with what's available for public consumption, it's not like you really need a GUI boot selector, just bells and whistles.

[Kabyl]

The GUI boot selector is waiting for an efi boot loader to boot OSX,

There are already many of what people call "an efi boot loader to boot OSX" (Chameleon 1.0.11 ?), or are you looking for something specific? do you expect to be helped, if you provide no details?

 

when the project is in end-user form then a release and source will be available as complete packages, it's not broken, just incomplete.

And when the version of Chameleon we're working on is in end-user form, then a release with code source, will be available for you and everyone to play with. And I don't want to keep repeating myself about this.

 

Releasing code that is incomplete makes no sense unless the project is being abandoned which it isn't,

I don't know how you expect us to give you access to the current incomplete sources, while it doesn't make sense to you in the first place.

And since you seem to be stuck, it would make sense to release your current sources and provide more details if you want to be helped.

 

it might be easier since you guys have released binaries without source ...

I don't see any binaries with unreleased sources in the Chameleon site, so I don't really know what you're talking about.

 

... to forego the GUI and make what I have work with what's available for public consumption, it's not like you really need a GUI boot selector, just bells and whistles.

If you're using syslinux or grub as a boot selector (are you?), and since the state of your work changed from being in need for fixes, to incomplete, then my guess is it's separated from the Chameleon binary (boot or boot2), but only dependent in functionality. So for this, it's just about features needed to complete the working of the whole package.

The answer is: wait and learn to be patient, or try to post about your issues asking for help and ask nicely.

 

If what you're doing involves the modification of the Chameleon boot loader sources, then in short, you're just a hypocrite.

 

-Kabyl

[Guest BuildSmart]

There are already many of what people call "an efi boot loader to boot OSX" (Chameleon 1.0.11 ?), or are you looking for something specific? do you expect to be helped, if you provide no details?

And when the version of Chameleon we're working on is in end-user form, then a release with code source, will be available for you and everyone to play with. And I don't want to keep repeating myself about this.

I don't know how you expect us to give you access to the current incomplete sources, while it doesn't make sense to you in the first place.

And since you seem to be stuck, it would make sense to release your current sources and provide more details if you want to be helped.

I don't see any binaries with unreleased sources in the Chameleon site, so I don't really know what you're talking about.

If you're using syslinux or grub as a boot selector (are you?), and since the state of your work changed from being in need for fixes, to incomplete, then my guess is it's separated from the Chameleon binary (boot or boot2), but only dependent in functionality. So for this, it's just about features needed to complete the working of the whole package.

The answer is: wait and learn to be patient, or try to post about your issues asking for help and ask nicely.

 

If what you're doing involves the modification of the Chameleon boot loader sources, then in short, you're just a hypocrite.

 

-Kabyl

There are versions of chameleon floating around in various distros that load DSDT and /Extra/.... which the source is not available so stop claiming no binaries without sources are being distributed, zef gave me binaries that do these things and have the BadAxe boot issue fixed, these are not in the 1.0.11 source.

 

You are the only one who claims that some code is broken because I've been waiting for a release with source.

 

What I see is that chameleon source has not been publicly updated for some time and posted release deadlines have not been met and status updates are few and far between.

 

Post about my issues, I require the chameleon source that has at the very least the DSDT and /Extra functionality and I've been more than patient in waiting like everyone else has been.

 

Hypocrit?? what drugs are you on, of course the source needs to be modified, it would be unusable in it's current state, if it at least has the required functionality then the amount of work required is minimal.

[Dense]

There are versions of chameleon floating around in various distros that load DSDT and /Extra/

 

These are modifications done by other people and were based on the existing 1.0.11 sources. It is not a Chameleon modification that was done by zef. The internal work in progress has its own implementation of these modifications. If you look around you'll also find the DSDT source additions by mackerintel (he posted his diff). The /Extra change is only a few lines of code that I am sure you can handle yourself.

[Guest BuildSmart]

These are modifications done by other people and were based on the existing 1.0.11 sources. It is not a Chameleon modification that was done by zef. The internal work in progress has its own implementation of these modifications. If you look around you'll also find the DSDT source additions by mackerintel (he posted his diff). The /Extra change is only a few lines of code that I am sure you can handle yourself.

I see so zef gave me someone else's work, nice to know.

[Dense]

I see so zef gave me someone else's work, nice to know.

 

Will you quit it with the attitude. He tried to help you out with a version that seemed to fix a problem.

 

The details of the development of Chameleon versions after 1.0.11 is complicated. Basically there were a number of derivative version made by people such as munky, mackerintel, fassl and turbo. There were also internal CVS revisions used to test some very minor changes that were part of what is eventually going to be either 1.5 or 2.0. The Chameleon developers (now under the Voodoo branding) have become unified with munky, mackerintel, fassl and indi join the development efforts. All their work in their derivative versions has been either rewritten or massively enhanced.

 

No one is trying to break license agreements. This isn't a group trying to horde the sources or control the community. Take off your tinfoil hat for once and consider that we are only trying to unify the community by putting out quality, feature complete releases.

[justvisiting]

Well you quit it with the attitude. He tried to help you out with a version that seemed to fix a problem.

 

The details of the development of Chameleon versions after 1.0.11 is complicated. Basically there were a number of derivative version made by people such as munky, mackerintel, fassl and turbo. There were also internal CVS revisions used to test some very minor changes that were part of what is eventually going to be either 1.5 or 2.0. The Chameleon developers (now under the Voodoo branding) have become unified with munky, mackerintel, fassl and indi join the development efforts. All their work in their derivative versions has been either rewritten or massively enhanced.

 

No one is trying to break license agreements. This isn't a group trying to horde the sources or control the community. Take off your tinfoil hat for once and consider that we are only trying to unify the community by putting out quality, feature complete releases.

 

I don't wish to continue a flame war, but to take a step back and look at things -- if someone works on a project, and sends a binary of that project to anyone, _without_ the source for that binary -- that is breaking your own license.

 

 

It will be interesting to see what goodies come out of the collaboration for the new chameleon/voodoo. thanks for the work.

[THe KiNG]

I don't wish to continue a flame war, but to take a step back and look at things -- if someone works on a project, and sends a binary of that project to anyone, _without_ the source for that binary -- that is breaking your own license.

That "anyone" in 99.9% cases is a tester and the source is not required in all cases unless he can contribute, as you probably know nobody can work w/o testers... Now if that "anyone" breaks the trust and came up on forums and start flaming or worst "share" the source with psystar or other "smart" companies is not the developer/s fault...

 

Tired to see so many people bitching and complaining, using multiple nicknames to add more flame and start more conflicts in this forum...

Also tired to see you BuildSmart "fighting for justice" (LOL) popping up in every topic that have something to do with Voodoo Team work, I know is hard for you to be out of this but seriously get a life...

[Dense]

I don't wish to continue a flame war, but to take a step back and look at things -- if someone works on a project, and sends a binary of that project to anyone, _without_ the source for that binary -- that is breaking your own license.

 

During development that is absolutely normal. The license doesn't say when the source code must be released just that it has to be released. This is a very common issue that comes up with GPL software. I would consider during development it is entirely reasonable that test versions are being sent around without source code. Once released to the general public, source could must be made available which has always been done with Chameleon. Consider in the situation above that BuildSmart is the tester.

 

This is just BuildSmart trying to turn nothing into something. As usual, development will continue on the next version of Chameleon and when its released, source code will be simultaneously made available.

[justvisiting]

...Tired to see so many people bitching and complaining, using multiple nicknames to add more flame and start more conflicts in this forum...

 

no mulitple nicknames, there is only one justvisiting

 

OK, enough thread polluting. I wonder what AnV is coming up with next. if he even cares to follow all that's happened to his thread.

[THe KiNG]

no mulitple nicknames, there is only one justvisiting

 

OK, enough thread polluting. I wonder what AnV is coming up with next. if he even cares to follow all that's happened to his thread.

That was not for you...notice the space betwin phrases...

[mitch_de]

Insted rumbling here better put some news + dev information on the chameleon homepage - latest entry 24 October 2008

[sonotone]

Insted rumbling here better put some news + dev information on the chameleon homepage - latest entry 24 October 2008

Think they understood, no need to repeat it again and again...

[triptolemos]

hey andy,

 

Nice job man!

 

en de beste wensen vast

[zef]

I see so zef gave me someone else's work, nice to know.

 

If i remember correctly i gave you an updated version of boot1h which can deal with case sensitive hfs+ filesystems - which is also my work. That should be released with 1.0.12 but instead we're working on this 'big' loader and delayed the release for the 1.5 version.

 

Please be patient guys, everything will be shared (as usual) with the new release but don't be so demanding with the 'deadlines' and overall. This is a hobby-part time project and it makes me feel a bit weird when _i_ have to say excuses...

 

Peace,

zef