On 22.03.2007, at 22:10, Michael Smith wrote:
On Mar 16, 2007, at 5:47 AM, Andreas Fink wrote: On 16.03.2007, at 11:34, Michael Smith wrote:
Really wish you-all would make the whole developer pkgs ready before releasing a massive update like 10.4.9 is.
You would really hold up a release like this until the open-source bits were ready? Somehow, I don't think you quite comprehend the reality of the situation.
Yes but why not releasing the source to the people who just received the released binary? Thats what usual open source licenses ask you to do.
I think you are perhaps confused here.
The source won't change after the binary is released that so it should be on the server right away.
You are making the assumption that:
a) the source as released is necessarily exactly the source that was used to build the product
That's what someone would expect if its OPEN source. Otherwise the kernel should be declared CLOSED source as its source is not revealed (or at least the difference between the released binary and the released source).
b) the source can be packaged immediately for distribution in the format that it was in when the product was built
out of the previous statement this is automatically derived...
Neither of these are true. In addition, you truly have no idea of the scope of the work involved to identify, scrub, validate and package the number of source code projects involved in a Darwin source release.
We're talking about ONE project here, the kernel itself. Not about all the other tools etc which might have many different licensing issues etc. I agree that validating packages of many source code projects can be time consuming but this has to be done anyway BEFORE the release of a binary as the binary wouldn't work. So when the binary has been produced, the source which this exact binary was built from is what really is what should and must be published (given that one is considered open source).
On top of that, Kevin (the chap who does all of this work, and whose long suffering you are at least partially responsible for) has a team to manage and real deliverables related to shipping the product that consumers actually want and pay for.
Since he has an open spot for an engineer to work on this packaging process, perhaps you'd front up and take the job?
: ) Well, I applied for a job at Apple in 2000 but they tend to ignore international developers so I jumped on Cisco.... Now I'm back in europe and California is no longer an option. But I wouldn't mind helping in some way. (never ask someone to fix something if youre not ready to do your part of it...) The SCTP driver project I'm participating in is something we wanted Apple to have as its an important new protocol and everyone in that group wanted to help Apple to have it integrated. There are kernel patches for it, a KEXT version of it. The only thing to make it independent of the kernel is a generic API to load a protocol handler. However, this API has never been fixed by Apple even though promised many times. Its the reason why SCTP.kext is still kernel dependent (means another binary for 10.4.6, one for 10.4.7, one for 10.4.8. etc just because of one version number). We discussed that during WWDC 2005 again during WWDC 2006 (and we will again during WWDC 2007) and the answer at the time was "probably in 10.4.6 we will have it but for sure in 10.5". Now currently it doesnt look like 10.5 but 10.6 or maybe in 11.0 or never. Simply because of shortage in resources inside Apple (which I can totally understand). The problem here is that we have no other choice than to be kernel dependent. Well there is one option which is to do it as a IP packet filter but this would be braindamage to go this road. SCTP on the other hand is cruical in the business are we work. I'ts not an option, its mandatory. And those guys buy telehouses full of equipment sometimes.
Anyhow, open source is all about people helping others to make better products. There's a bunch of people behind SCTP.kext including some authors of the RFC's itself. And it has been integrated into multiple operating systems (mainly BSD's) and is part of some official kernel releases. Only under MacOS X it gets stuck because of the source not being available of 10.5 until 10.5 is being released and even then, it might be a different source we will look at as we now figured out. So open source developers start to loose energy and time.
I have this problem with 10.5. Our driver doesn't run under 10.5 anymore. But because the source is not available yet, I can't even prepare for 10.5 to fix the issue. So we can start fixing only after 10.5 is out and only a few month later (if we are lucky) the source of it will be made available while all the customers will rush and go and buy 10.5 and install it and then realize it failed where its a pain to move back.
Nonsense. Apple has been preparing third party vendors for Leopard for a long time; there have been many 10.5 seeds, and DTS are more than happy to support ADC members looking to get their products ready in time.
DTS was not able to help me because there's no official API and because the source of 10.5's beta builds are not available. And I'm ADC member since the days where AppleLink was still the main communication method. It all stands and falls with being kernel dependent. I wish we wouldnt be kernel dependent and we wouldnt have this discussion at all. But this is a fact because of missing API. THATS what's really needed.
I'm talking about SCTP, a third party kext which is kernel dependent which Apple has not yet added to its kernel. There is a very good reason why its kernel dependent and Apple has not changed that by providing an open API. I had many many discussions with Vincent and others about this.
Availability of the Darwin source base is not an absolute gating factor; if you care about being ready for Leopard as a developer, there are avenues open to you.
No thats just the point. Without the Leopard source (actually only a bunch of header files and a few source files, we dont need the rest), the kext can not be adapted. I think the adaptions will be minor (it was bigger from 10.3 to 10.4).
in other words, we are being dependent on something which has very slightly changed in Leopard and we have no way on figuring out HOW it changed. Probably only an additional field moving a structure a bit around or so but without having the headers Leopard was build against, there's no way of ever finding out.
Give me a good reason why the source should not be released at the day of the binary is released.
Because it is *not ready* to be released.
which comes back to the point that released binary <> released source. This is BAD. It violates the basic rules of open source.
The binaries are released. If the sources aren't ready, how did they build the binaries?
You're making the same mistakes Andreas is; namely that the source as released is necessarily identical to the source used to build the binaries, *and* that all of the incidental work (legal, logistical, etc.) is being done before the release is cut.
Again, thats what all is about in open source. So apple should go out and say, "Hey here is SOME kernel. Its not the one of MacOS X. It's another one. You can play with it but we're not responsible for any damages etc.e tc.".
but Apple says "This is the source of the MacOS X kernel" and actually its not...
But lets stop arguing about politics and get the work done... send me xnu.tar.gz of Leopard and we send you a diff to add SCTP to it and it will be all fine :-) (your lawyers probably will kill you if you did..., no I'm not suggesting to suicide...)
I'll throw out the same challenge I did to Andreas to anyone else that feels like griping: if you feel so very strongly that the Darwin source releases should be out sooner, talk to Kevin about a job. I believe that this is the open req:
But you should verify; his contact details are plastered all over these lists, and if you're a serious follower of the Darwin source releases you know who I'm talking about.
Andreas Fink
Fink Consulting GmbH Global Networks Schweiz AG BebbiCell AG
--------------------------------------------------------------- Tel: +41-61-6666330 Fax: +41-61-6666331 Mobile: +41-79-2457333 Address: Clarastrasse 3, 4058 Basel, Switzerland --------------------------------------------------------------- ICQ: 8239353 MSN: email@hidden AIM: smsrelay Skype: andreasfink Yahoo: finkconsulting SMS: +41792457333
|