Jump to content

Update to DaemonES kernel source.


Guest BuildSmart
 Share

28 posts in this topic

Recommended Posts

Guest BuildSmart

Here is the updated patch that allows you to build a kernel for sse3 emulator bin-patching or sse3 emulator patchless depending on the build flag used.

 

I have successfully tested this patch against the 8.9.1 and 8.9.2 kernel source.

 

To generate a kernel that requires bin-patching:

make OBJROOT=/xnu-792.18.15.obj~6

To generate a kernel that doesn't require patching:

make NOPATCH=YES OBJROOT=/xnu-792.18.15.obj~6

 

For posting compliance purposes the security key has been removed, it is common knowledge so research it if you don't know it.

 

New build flag added in update:

make SHOWKEXT=YES OBJROOT=/xnu-792.18.15.obj~6

To generate a kernel that doesn't require patching:

make NOPATCH=YES SHOWKEXT=YES OBJROOT=/xnu-792.18.15.obj~6

 

CheckSums:

MD5 (daemones_1049.tar) = e1815ecf8ccda4e482164eae9fe43f9e
MD5 (daemones_1049.tar.gz) = 0adb014da29fce27e616d4409df695a9
MD5 (daemones_1049_update.tar) = e69ece105d30a9191ed1d151fc35ee09
MD5 (daemones_1049_update.tar.gz) = 5823d9045a067a0d4c9041d86923f88b

 

 

Well, netkas gave permission to post his kernel diff so it here it is along with the semthex diff so it looks like the only things missing are the last 6 months worth of fixes, thanks for contributing netkas as we move one step closer to open development.

 

CheckSums:

MD5 (nebukadnezar_1048.tar) = 078bb1178af5a9f0a5d9f1fa38864db3
MD5 (nebukadnezar_1048.tar.gz) = e595d22614844804af341e5e1b4cd221
MD5 (semthex_1048.tar) = e7f768081d89a9525d0531a2fb82c0b7
MD5 (semthex_1048.tar.gz) = 8143c4dbfbbed5d2246907c489550133

 

P.S.: netkas, you don't make me angry, you just annoy me when you tell your lies but if you want to run around telling people you make me angry it's just another lie your spreading and it really only hurts your credibility and value.

daemones_1049.tar.gz

daemones_1049_update.tar.gz

semthex_1048.tar.gz

nebukadnezar_1048.tar.gz

Edited by BuildSmart
Link to comment
Share on other sites

Here is the updated patch that allows you to build a kernel for sse3 enulator bin-patching or sse3 enulator patchless depending on the build flag used.

 

I have successfully tested this patch against the 8.9.1 and 8.9.2 kernel source.

 

To generate a kernel that requires bin-patching:

make OBJROOT=/xnu-792.18.15.obj~6

To generate a kernel that doesn't require patching:

make NOPATCH=YES OBJROOT=/xnu-792.18.15.obj~6

 

For posting compliance purposes the security key has been removed, it is common knowledge so research it if you don't know it.

 

Awesome!!!

Link to comment
Share on other sites

Guest BuildSmart
it's much better to create kernel which will autodetect sse3 and then.... can't you ?

netkas, out of courtesy I will post a sensible response to your query but in the future I would prefer that you refrain from responding to my topics/posts.

 

SSE3 is already detected by the kernel and flags set.

 

My understanding of the SSE3 emulator source code interpretation is that if an SSE3 instruction is executed on a CPU that doesn't support the particular instruction it generates an error and the error handler then takes over and utilizes the SSE3 emulator code for that instruction, it doesn't need to be any more complicated than that and no speed saving would be gained by utilizing a different method because those CPU's that support the instruction set would never use the emulator code and never be slowed down.

 

The only thing I can see is that if SSE3 is detected then moving the emulator to the commpage can be skipped but I fail to see the advantage of this.

Link to comment
Share on other sites

Time for a constructive post:

 

I tried the 10.4.9 source with the diff applied. I compiled it without the need for binpatching and I test booted it. On the startup, i noticed it said that HPET was enabled, even when it shouldn't have been. It has been getting stuck on Configuring Kernel Extensions.

 

There, some helpful information. Now help me fix it. :(

Link to comment
Share on other sites

Guest BuildSmart
Time for a constructive post:

 

I tried the 10.4.9 source with the diff applied. I compiled it without the need for binpatching and I test booted it. On the startup, i noticed it said that HPET was enabled, even when it shouldn't have been. It has been getting stuck on Configuring Kernel Extensions.

 

There, some helpful information. Now help me fix it. :P

Yes, your reply is on topic, thank you.

 

OK a couple of issues.

 

How can you compile without the need for bin-patching when you don't have the sse3 emulator integrated source?

 

The HPET code in the diff detects if HPET is available and if so enables the flags.

 

If your CPU doesn't support HPET then it shouldn't enable, I have a P4 without NX/HPET and I don't have the issue you are encountering and you are not providing enough techinical information to determine the true cause of your problem.

 

Strangely enough I haven't heard from anyone else that they are experiencing this problem so I can't comment further.

 

I suggest you make 3 edits and force HPET to be off no matter what and if it still enables then I'd say that you have an extension that is enabling the HPET and is the root of your problem ("grep -rn nx_enabled ." and make them "= 0" or "= FALSE" to force it off).

 

it was posted on semthex blog a while ago :gun:

 

and, there is one problem with emu and acpi, it become when....i let you find it

oh sorry our dictator....

It seems netkas can't generate a post without causing a problem and this so called peace treaty he claims he made is non-existant.

 

His last post was more antagonistic than useful.

 

It's post like his last one that dirty up topics and is the reason why I wish he would refrain since he's obviously too childish to contribute in a meaningful manner and his childish antics only make it difficult for the reader to have to read through this {censored}.

 

I'll tell you what netkas (also known as OoOoOoO), if you don't stop the childish games, I will post your kernel source diff and semthex's kernel source diff, I can legally post it because it is based on the APSL kernel source (read it) and you can't re-license it without written authorization from apple which they will never provide so it can be freely distributed and I don't need your permission, the fact that I have not released it has nothing to do with my lack of respect for you as an individual and you should jusrt consider it a blessing.

 

You gave it to someone and they gave it to me so there is no theft involved so don't start telling lies about theft and stolen code again because it just isn't true and everyone will see this.

 

I do not have to provide the source of your file, it is irrelevent but to show proof here is a partial segment:

+++ nebukadnezar_sse3_final/osfmk/i386/AT386/model_dep.c	2006-12-24 11:26:29.000000000 -0100
@@ -365,6 +365,11 @@
	if (reboot) {
		printf("MACH Reboot\n");
		PEHaltRestart( kPERestartCPU );
+		asm volatile (
+			"movb $0xfe, %al\n\t"	
+			"outb %al, $0x64\n\t"		
+			"hlt\n\t"				
+			);
	} else {
		printf("CPU halted\n");
		PEHaltRestart( kPEHaltCPU );

look familiar???

 

Now, if you can't play nice and be respectful in public I will make those files publicly available to everyone instead of quietly providing them in the background.

Link to comment
Share on other sites

How can you compile without the need for bin-patching when you don't have the sse3 emulator integrated source?

 

What?

 

I thought that you provided it in this source. If you are sharing others work, why don't you share your own so that people can benefit from your work too?

 

Just a thought...

 

EDIT: by the way:

 

My-Computer-2:~ User$ md5 /Users/user/Desktop/daemones_1049.tar

MD5 (/Users/user/Desktop/daemones_1049.tar) = e1815ecf8ccda4e482164eae9fe43f9e

My-Computer-2:~ User$ md5 /Users/user/Desktop/daemones_1049_update.tar

MD5 (/Users/user/Desktop/daemones_1049_update.tar) = e1815ecf8ccda4e482164eae9fe43f9e

Link to comment
Share on other sites

Guest BuildSmart
What?

 

I thought that you provided it in this source. If you are sharing others work, why don't you share your own so that people can benefit from your work too?

 

Just a thought...

 

EDIT: by the way:

 

My-Computer-2:~ User$ md5 /Users/user/Desktop/daemones_1049.tar

MD5 (/Users/user/Desktop/daemones_1049.tar) = e1815ecf8ccda4e482164eae9fe43f9e

My-Computer-2:~ User$ md5 /Users/user/Desktop/daemones_1049_update.tar

MD5 (/Users/user/Desktop/daemones_1049_update.tar) = e1815ecf8ccda4e482164eae9fe43f9e

A mistake on my part, it has been corrected.

MD5 (daemones_1049.tar) = e1815ecf8ccda4e482164eae9fe43f9e
MD5 (daemones_1049.tar.gz) = 0adb014da29fce27e616d4409df695a9
MD5 (daemones_1049_update.tar) = e69ece105d30a9191ed1d151fc35ee09
MD5 (daemones_1049_update.tar.gz) = 5823d9045a067a0d4c9041d86923f88b

 

Demanding I fix a problem that only you seem to be experiencing is not part of my job description however I will provide you with information to help you isolate the problem where I can which is what I have done, fixing the problem is up to you since I can't duplicate the problem and don't have your hardware and you can't isolate the exact cause how can I fix it and since you claimed to be a programmer or have some programming skills how come you can't find the cause and fix it yourself?

 

I am sharing the base kernel source code becuase this has been given to me to openly share and since there isn't any open kernel project for me to participate in I see no reason to share anything more than the base code and minor fixes to it until such time that an open kernel project does exist.

 

As I have been stating, when there is an openly shared kernel project I will participate in it and will submit my version of the sse3 emulator source code, in the interim, everyone is welcome to use the bin-patch method since it does yeild a working kernel.

 

I understand that their is a newer version of the bin-patching PHP scripts however the updated version has not been posted so the PHP scripts I have provided will have to suffice unless someone wants to spend a little time and update them.

 

On another note, I'm not about to release source code to be plagiarized by the current closed kernel dev group so when they start sharing their source I will too.

 

Now, my irc chat logs show that you stated you had the latest semthex kernel source code that netkas gave you, why are you not using it since it is claimed to be far more advanced than the DaemonES kernel source (I can't validate this claim because I don't have their latest source) and how come your not sharing this latest semthex source you do have (or claim to be in posession of)?

 

It looks like you want what I have but are not willing to share anything you have, interesting concept, guess your not interested in participating in an openly developed kernel project.

 

It is covered under the APSL and sharing is permitted and you don't require the groups authorization to share it but I do understand they preffer that you not share it and finally, why are they not fixing your problem since it is their latest source you do have (or claimed to be in posession of)?

 

Now while I do have some diff's for semthex and netkas source code, I'm failrly confident that the diff's I do have are a little aged and I haven't found anything extremely usefull in them however there are some differences in the way in which some functions are written but I haven't spent the time determining which is the better code so I have not adopted any of them as of yet.

 

I'm not interested in developing a kernel myself but I am interested in contributing to an open kernel project when it exists.

 

Time for a constructive post:

 

I tried the 10.4.9 source with the diff applied. I compiled it without the need for binpatching and I test booted it. On the startup, i noticed it said that HPET was enabled, even when it shouldn't have been. It has been getting stuck on Configuring Kernel Extensions.

 

There, some helpful information. Now help me fix it. :P

Just a thought that crossed my mind, you do understand what

PE_parse_boot_arg("nohpet", &noHPET)

means don't you???

 

In case you don't, it means you can use "nohpet" in your boot arguments

Link to comment
Share on other sites

Guest bikedude880

Hey come on guys, this is about the most childish thing any of you can do. This whole thing has become a horrible battle between a few people and it's affecting the whole community. Granted the sources that BuildSmart has aren't the latest and greatest, who cares? He's working on his own view of how the kernel should work. These posts... no, there is a better word for it... flame-posts are completely unnecessary. Keep in mind who you are representing each time you post that filth.

 

In other news and more on topic, keep up the good work. Friendly competition is healthy, what's going on here isn't.

Link to comment
Share on other sites

Guest BuildSmart
Hey come on guys, this is about the most childish thing any of you can do. This whole thing has become a horrible battle between a few people and it's affecting the whole community. Granted the sources that BuildSmart has aren't the latest and greatest, who cares? He's working on his own view of how the kernel should work. These posts... no, there is a better word for it... flame-posts are completely unnecessary. Keep in mind who you are representing each time you post that filth.

 

In other news and more on topic, keep up the good work. Friendly competition is healthy, what's going on here isn't.

Surprising words of wisdom coming from you.....

 

All I'm trying to do is provide the ability to openly develop the kernel without harrassment, every time I post something netkas has some ambiguos flamebait comment to make based on lies and taunting, he has not contributed in a meaningful manner and IMO it would be best if he just refrained from posting since he's not contributing to the spirit of open development or the benefit of the community.

 

Myself like many others have little respect (if any at all) for him because he does nothing but spread lies.

 

His god complex isn't helping his cause, I've recieved several PM's from those taking up the project but don't want to get involved publicly because they don't want to be subjected to his childish {censored} and I can't blame them.

 

If I could get the management here to allow me to have a forum for an open kernel project I would remove those kinds of posts becuase they are not conducive to the community and like others I'm tired of defending myself from the lies he's posting and censorship of non-related or non-productive material seems to be the only way to prevent this kind of behavior because he has no respect for the community or IM in general as he has clearly posted on other sites.

 

Of course his lies only make him look less than desirable and hurt his credibility more in the long run but he's blinded by his own glory seeking to see this.

 

Now I'm not saying I'm perfect cause I've said a few things about him myself becuase I'm getting tired of dealing with his {censored} but at least the things I have said are true.

 

Bottom line is this, he's no better than anyone else here and he doesn't deserve any special treatment or privilidges and if he can't participate in a productive and meaningful manner then he shouldn't be here, of course this is true for everyone but everyone else is not posting here to purposely cause a problem.

Link to comment
Share on other sites

There are only a couple people who ever made contributions to kernel sources: Vitaliy Pronkin aka. mifki (who's been out of the scene since Nov/Dec 2006), Dmitri Arekhta aka. Daemon (who made mostly minor/experimental contributions, and whose latest patch you already have), semthex (whose latest code, minus SSE3, is xnu-1048-semthex-2 + nebukadnezar patch), and Paulicat (author of EST and sleep-fix patches, whose source you undoubtedly possess by way of Kiko). Yes, nebukadnezar sources are essentially the latest kernel semthex used, up to the AppleTV build around the time he quit. Perhaps netkas made some minor changes in the post-semthex era, with nothing of note prior to it either.

 

You seem to be hunting for some ghost sources that are nothing more than a figment of your imagination. Please explain what already-implemented features you are seeking to see source for (other than SSE3 emulation, which according to lore has always been done by bin-patching). I would consider myself very lucky to have the resources you do, despite the fact that you've become enemies with virtually everyone.

 

Incidentally, all the people mentioned above are gone. And as I said before, netkas hasn't really made any major modifications. You keep begging to be part of some secret, elite group of developers which simply doesn't exist. It did once, of course, but certainly not anymore. You played a considerable role in the destruction of what remained of OSx86 development, so please - for the hundredth time - either pick up the pieces (which you already possess), start your own project, or move on to better things in life, as everyone else of note has done.

 

And a final note about this rather moronic "flame-war." The first rule of the internets, BuildSmart: if you don't like it, ignore it. Oversensitivity is a characteristic which will bring you a quick demise in this community. :thumbsdown_anim:

Link to comment
Share on other sites

well, thats pretty much it. the only one or two changes not in nebukasander iirc are the nd2-x series of kernels, but you have the daemones code. so just port some code over

Link to comment
Share on other sites

Guest BuildSmart
There are only a couple people who ever made contributions to kernel sources: Vitaliy Pronkin aka. mifki (who's been out of the scene since Nov/Dec 2006), Dmitri Arekhta aka. Daemon (who made mostly minor/experimental contributions, and whose latest patch you already have), semthex (whose latest code, minus SSE3, is xnu-1048-semthex-2 + nebukadnezar patch), and Paulicat (author of EST and sleep-fix patches, whose source you undoubtedly possess by way of Kiko). Yes, nebukadnezar sources are essentially the latest kernel semthex used, up to the AppleTV build around the time he quit. Perhaps netkas made some minor changes in the post-semthex era, with nothing of note prior to it either.

 

You seem to be hunting for some ghost sources that are nothing more than a figment of your imagination. Please explain what already-implemented features you are seeking to see source for (other than SSE3 emulation, which according to lore has always been done by bin-patching). I would consider myself very lucky to have the resources you do, despite the fact that you've become enemies with virtually everyone.

 

Incidentally, all the people mentioned above are gone. And as I said before, netkas hasn't really made any major modifications. You keep begging to be part of some secret, elite group of developers which simply doesn't exist. It did once, of course, but certainly not anymore. You played a considerable role in the destruction of what remained of OSx86 development, so please - for the hundredth time - either pick up the pieces (which you already possess), start your own project, or move on to better things in life, as everyone else of note has done.

 

And a final note about this rather moronic "flame-war." The first rule of the internets, BuildSmart: if you don't like it, ignore it. Oversensitivity is a characteristic which will bring you a quick demise in this community. :)

I'm not hunting for some mysterious ghost source, I just believe that the reinventig the wheel is a waste of valuable time.

 

I'm enemies with virtually everyone? I find that hard to believe, I find it easier to believe that I'm not liked by the closed kernel dev group due to my push towards open development.

 

Now if that group doesn't exist any more then their work should be publicly available for people to take up the plight and continue where they left off but those who are in posession of it aren't willing to share because they are more interested in the glory than in the projects advancements.

 

That first rule of internet your directing towards me, perhaps you should explain that to netkas, then I wouldn't have to waste my time straightening out his lies and/or defending myself and if you go and look at the other threads, you're a contributor as well so don't try to make yourself out to be better than anyone eles when you're just as guilty as anyone else, we're all equal here.

 

netkas makes it a point to taunt and brag about how this is fixed and how that is fixed (one that I confirmed isn't fixed properly) and these fixes are submitted by other individuals like mifki, it is these code fixes that are beneficial.

 

At least by making the source patches publicly available, if someone wants to make undertake writting a fix for something that has already been done but not shared they can do so and should be able to do so un-harrassed by netkas and those like him.

Link to comment
Share on other sites

Guest bikedude880
These are your conjectures

you lie

netkas, I admire the work you've done but you're just making a fool out of yourself by posting all of this. I'm advising you to stop and let BuildSmart do his thing. I'll be contacting you shortly.

Link to comment
Share on other sites

BuildSmart: are you really so obtuse that you still don't realize what I'm trying to say? Forget netkas, he is and has been irrelevant. You have the sources. What's been done has been available. Explain, in very specific terms, which items are not yet available to you - and if there really is something missing, why it's so non-trivial that it can't be easily replicated.

 

Maybe you're not all fools, but the lack of real development from anyone these past months makes it seem that way. Everyone with a shred of competence has gone (or never entered development in the first place).

Link to comment
Share on other sites

Guest BuildSmart
you lie

Are you some kind of idiot?

 

You claim that the 64bit issue is resolved and I have a Pentium-D in an EFI enabled motherboard and it still doesn't work so that to me is confirmed.

 

I have a Celeron-D in another EFI enabled motherboard and if I disable EFI it works but as long as EFI is enabled it get's the "Bus error" so this to me means that it is partialy fixed.

Link to comment
Share on other sites

Guest BuildSmart
BuildSmart: are you really so obtuse that you still don't realize what I'm trying to say? Forget netkas, he is and has been irrelevant. You have the sources. What's been done has been available. Explain, in very specific terms, which items are not yet available to you - and if there really is something missing, why it's so non-trivial that it can't be easily replicated.

 

Maybe you're not all fools, but the lack of real development from anyone these past months makes it seem that way. Everyone with a shred of competence has gone (or never entered development in the first place).

Some of the code is trivial yes, like the advanced cpu detection code that DaemonES promised to provide but since getting involved with semthex and netkas he's not followed through for some unknown reason.

 

Now as netkas points out, there's a fix (written by mifki) for the 64bit issue that is 99% effective that involved a rewrite of some 64bit handling routines along with a handfull of bug fixes that I certainly don't want to waste time writing since they exist but since mifki's involvement with semthex and netkas he's not openly sharing these fixes either.

 

I have not seen any 10.4.9 related material from anyone and the provided DaemonES 10.4.9 patch is the 10.4.8 patches ported to the 10.49 source.

 

I have made several attempts to discuss these things with those who have submitted fixes for various things and rather than allowing me to discuss the fixes with the submitter(s) they banned me from the irc but unknown to them I ARD to a server in another state I have access to and I quietly sit in the channel while they talk about me behind my back making up lies and twisting the truth to justify their stupidity and to prevent the public release of some of the fixes.

 

As I said, no one wants to re-invent the wheel and I, like many others believe by allowing un-harrassed public and open development, that further kernel advancements will be achieved.

 

While I have no issues with the .9 DaemonES kernel due to my specific needs and I fixed minor bugs/issues pointed out to me, it certainly isn't something that I would consider ready for the masses since it lacks some of the fixes that are desirable.

 

I have already shown a user that it is possible to modify Intel motherboard firmware to natively boot from efi and to boot an unpatched install DVD by providing a live video feed of the booting machine (and I used a gateway computer as my first guinea pig) however this modification is costly in development time and resources not including the licensing and NDA agreements with Intel and AMI so between work, the BIOS project and some other obligations a lot of time to write from scratch routines and fixes that exist isn't available for me and no one wants to publicly get involved in a kernel project because of the harrassment netkas inflicts and I believe it's because he's feeling threatend by the thought of being removed from the spotlight where he get's his feeling of superiority.

 

I'm not interested in the spotlight, I'm interested in advancements through an open environment and I'm not about to participate in or submit anything to be utilized and plagiarized by the current closed kernel dev group which has a history of this.

Link to comment
Share on other sites

Are you some kind of idiot?

 

You claim that the 64bit issue is resolved and I have a Pentium-D in an EFI enabled motherboard and it still doesn't work so that to me is confirmed.

 

I have a Celeron-D in another EFI enabled motherboard and if I disable EFI it works but as long as EFI is enabled it get's the "Bus error" so this to me means that it is partialy fixed.

 

The finer points of kernel hacking may be beyond my abilities, but why are you comparing a Celeron-D to a Pentium-D? They are totally different processors; one has 2 cores the other has 1, one may or may not have x86-64, the other does. One might have EIST & Vxt, the other won't. I thought the problem was w/ pentium-Ds; where does the Celeron come into it.

Link to comment
Share on other sites

Guest BuildSmart
The finer points of kernel hacking may be beyond my abilities, but why are you comparing a Celeron-D to a Pentium-D? They are totally different processors; one has 2 cores the other has 1, one may or may not have x86-64, the other does. One might have EIST & Vxt, the other won't. I thought the problem was w/ pentium-Ds; where does the Celeron come into it.

All processors I tested are x86-64 and the issue is not limited to the Penmtium-D, upon further testing I've also found machines with Celeron-D's and P4's that have this issue and it's resolved for the most part with the latest kernel however none of these machines are EFI enabled or has the feature to enable it so no further testing can be done on them.

 

I switched out the Celeron-D for the Pentium-D on the board that has the ability to enable/disable EFI and as long as EFI is enabled it experiences the "Bus error".

Link to comment
Share on other sites

Are you some kind of idiot?

 

You claim that the 64bit issue is resolved and I have a Pentium-D in an EFI enabled motherboard and it still doesn't work so that to me is confirmed.

 

because you are brain damaged and can't even use ready solutions

 

diegomax tested - all fine, no more bus errors, other guys tested - all's ok, only you have strange problems, os it makes me think you have hard damaged brain.

Link to comment
Share on other sites

Guest BuildSmart
because you are brain damaged and can't even use ready solutions

 

diegomax tested - all fine, no more bus errors, other guys tested - all's ok, only you have strange problems, os it makes me think you have hard damaged brain.

 

Ready solutions??? you claimed the latest kernel fixes this and it doesn't.

 

I have a mothoard with a Pentium-D and the fix doesn't work on it so that is a confirmed failure to anyoe who can read plain english.

 

I am trying very hard to be the mature with you and I have had about as much of your lies and ignorance as should be permitted publicly, please don't force me into a situation that will affect you here, stop lieing, stop the name calling, if you can't act like an adult then please refrain from posting a response.

 

I think you all have said everything to each other that needs to be said. Now who ever can work together should and who can't, well then it's time to move on.

That is what I am attempting to do however some people are having an issue with the open development concept and appear to prefer spending time lieing about and attacking people.

 

JaS, during a previous conversation a couple of months back that you and I had, you were going to locate the documentation and notes for creating the install DVD's and the reason that you haven't provided them I will attribute to your busy schedule and was wondering if you had a projected dated when I could expect to obtain the stuff?

Link to comment
Share on other sites

I was also interested in JaS installation notes and scripts. I have spent some time working on this but it feels annoying trying to reinvent the wheel when its already been done. I'd certainly be interested in trying to build my own OS X DVD with customisations. I think at one time I had a script JaS uses but I lost it. It wasn't commented much but did seem fairly functional. Certainly provided me with some valuable information about how the process was done.

Link to comment
Share on other sites

  • 4 weeks later...
Guest BuildSmart
I was also interested in JaS installation notes and scripts. I have spent some time working on this but it feels annoying trying to reinvent the wheel when its already been done. I'd certainly be interested in trying to build my own OS X DVD with customisations. I think at one time I had a script JaS uses but I lost it. It wasn't commented much but did seem fairly functional. Certainly provided me with some valuable information about how the process was done.

I can understand the feeling, I've been sitting back waiting to see what develops and it looks like you can't count on people to provide the information they promise.

 

In the next month or two I'll be releasing a temporary solution to the no-patch kernel to help those interested in getting further ahead and I'll release my sse3 emu source as soon as some of those claimed fixes become available (if they ever do) however, I'm reluctant to share anything with a community that isn't willing to share with me and as the current kernel dev group is known for claiming others work as their own it's even more critical that everything be open and available to prevent this kind of behavior from destroying the concept of open development.

Link to comment
Share on other sites

 Share

×
×
  • Create New...