Mac OS 10.2.3 Released

[Doctor Q]

Originally posted by MacBandit
This could all just be done by program installers. They should just install needed resources for the computer it's being installed on.

I haven't seen the source code, so I'm wondering if "taking out support for all hardware but that which you have on your computer" is done by (1) making source code modifications or by (2) changing run-time configuration files. For example, both types of changes apply to the Apache web server and its use of modules.

If it's case (1), an installer couldn't do it since the code needs to be compiled after the environment is known. Instead of an installer, you'd have to use a "configure and make" process.

If it's case (2), an installer could do it. But then you could also do it by hand if somebody wrote the instructions. You wouldn't need a compiler, just an editor.

Am I understanding correctly, Shadowfax? Which case is it?

 

[MacBandit]

Originally posted by Doctor Q

I haven't seen the source code, so I'm wondering if "taking out support for all hardware but that which you have on your computer" is done by (1) making source code modifications or by (2) changing run-time configuration files. For example, both types of changes apply to the Apache web server and its use of modules.

If it's case (1), an installer couldn't do it since the code needs to be compiled after the environment is known. Instead of an installer, you'd have to use a "configure and make" process.

If it's case (2), an installer could do it. But then you could also do it by hand if somebody wrote the instructions. You wouldn't need a compiler, just an editor.

Am I understanding correctly, Shadowfax? Which case is it?

The point is either way Apple could right an installer program to do this.

 

[shadowfax]

Originally posted by MacBandit


This could all just be done by program installers. They should just install needed resources for the computer it's being installed on.

well, the problem is, it has to be done specifically at the time of compiling. you could conceivably compile a different binary package for each combination of hardware, but that seems like it would add up to a hell of a lot of space. you could also have a package manager configure the source code, like fink for source packages, which is really what i had in mind, but then it takes hours to compile and install. for instance, i would guess that compiling OS X would take nearly a week on a low-end system, maybe 36-48 hours for a dual 1.25 GHz PM. no set of consumers would ever deal with that. the real problem, though, is that apple would never give customers a copy of proprietary source. that would mean that (a) you would be able to see it and (b) you would be able to modify it, neither of which they want.

 

[shadowfax]

Originally posted by Doctor Q

I haven't seen the source code, so I'm wondering if "taking out support for all hardware but that which you have on your computer" is done by (1) making source code modifications or by (2) changing run-time configuration files. For example, both types of changes apply to the Apache web server and its use of modules.

If it's case (1), an installer couldn't do it since the code needs to be compiled after the environment is known. Instead of an installer, you'd have to use a "configure and make" process.

If it's case (2), an installer could do it. But then you could also do it by hand if somebody wrote the instructions. You wouldn't need a compiler, just an editor.

Am I understanding correctly, Shadowfax? Which case is it?

you have it exactly. to improve system perforrmance, the code would need to be recompiled completely. a post-compile config file is a common thing, something that undoubtedly apple uses already, but it won't help system performance, because the binaries are still packed with support for all that old junk. for instance, your OS X has support for G3 and G4, but you more than likely don't have both on your system, and don't need support for both of them. your installer DOES configure the OS for your hardware, but for the most part it doesn't change any binaries. an exception to this would be seen in, say, the developer tools apple releases. apparently at the very end of the installation it compiles some headers that it needs to have in binary form optimized for your system, and it takes a good while to compile.

 

[shadowfax]

Originally posted by MacBandit


The point is either way Apple could right an installer program to do this.

either way they could, of course, but they never would, for the reasons i mentioned and many others, i am sure, but primarily because you would never wait to compile the OS, or even a 50 MB update to it, which would probably then require you to recompile at least a good bit of the system, and they don't want to let you look at their source code.

 

[MacBandit]

Originally posted by Shadowfax


well, the problem is, it has to be done specifically at the time of compiling. you could conceivably compile a different binary package for each combination of hardware, but that seems like it would add up to a hell of a lot of space. you could also have a package manager configure the source code, like fink for source packages, which is really what i had in mind, but then it takes hours to compile and install. for instance, i would guess that compiling OS X would take nearly a week on a low-end system, maybe 36-48 hours for a dual 1.25 GHz PM. no set of consumers would ever deal with that. the real problem, though, is that apple would never give customers a copy of proprietary source. that would mean that (a) you would be able to see it and (b) you would be able to modify it, neither of which they want.

I understand the problem with basically security for Apples product but I didn't have a handle or knowledge of the times involved for the recompile. You are correct for the average consumer (that being 98% of all computer users) this method just wouldn't be acceptable.

Another day and another thing learned. This is how every day should go for everyone.