Aside from 'make -j2', which schedules multiple independent Make targets for concurrent execution, there is also 'gcc -pipe' which implies at least two processes.
There is a wall-time improvement just doing a "straight" (no application-level SMP support) compile of a large program such as the Linux kernel on a two-processor machine.
I think the first goal is to get Linux/i386 working, given that that's the easiest target for a port from Win32/i386 code that assumes sizeof(void*)==4 and little-endian byte order. Gotta walk before you can run. If you really want a PPC port, I suggest you start with the win32-compatibility library in Wine.
I've heard rumors that one of the Linux team has successfully made Wine (at least the source compatibility library portion of it) compile on Linux/PPC. It probably doesn't work due to the big-endian architecture, but it links without error. I have heard no rumors about anyone trying to make Corel Draw compile with it though.
Other rumors: the people on the team have access (either at home or at work) to Linux/Alpha, Linux/PPC, and Linux/strongARM. The team was derived from the Mac port team, so they have plenty of PPC hardware to test on.
GNU software is always better than commercial software _at the same level of maturity_.
Don't bother trying to compare ten year old commercial applications with GNU applications that have only existed for two years and have only been usable for half that time. The commercial software will usually (although not always) win such a biased contest.
Almost all software projects, commercial and GNU, have differences, and depending on the user's needs one will always be "better" than another. GNU software tends to be rich in documentation (the problem with Linux is not lack of documentation, it's way way way too much documentation in too many places), capability (features that are possible, but not necessarily implemented), extensibility (if there's no plugin interface, write one), reliability (doesn't crash) and portability (it's easy to be GNU-compatible).
These are all important to me, and over the last six years of using Linux I have learned that it is so unlikely for commercial software to provide this at a reasonable price (i.e. less than US$50K) that I no longer waste my time evaluating any kind of software for my personal use unless it comes with complete source code.
Commercial software tends to be rich in features (capabilities that have been implemented) and stability (doesn't change), and comes with bundled non-software products (such as hardware, technical support, and some kind of warranty) and obscure kinds of compatibility (usually with itself and its major competitors only, though). Note that it is possible to get all of these things from a vendor of GNU software, so these are not very large advantages for commercial software.
These are not important to me and some of them are actually drawbacks. For example, consider the amount of time and money required to characterize a problem in commercial software (which inevitably involves some reverse-engineering of the software because there is no source code to use as a reference), wait for vendor customer support, communicate the problem to the support person, communicate it again when they realize that they can't solve it on their own and have to get a technical person to handle the call, justify the business reasons for the solution to the problem, execute a contract for delivery of a fix to the problem, wait for delivery, verify that the delivered fix corrects the problem (which is not a 100% probable event I assure you), and pay for the privilege of doing all this work (which in some corporations is a chore in and of itself). We are talking about weeks here.
Now consider the amount of time required to characterize a problem in GNU software (less, because I can walk through the source code and see problems immediately), create a patch that fixes the problem, test the patch, send it to the product's maintainer, and have a new release of the software available to the general public. When I find and fix a bug in OSS, it's fixed _immediately_ and _forever_. We are talking about hours here. If I skip the parts about sending the patch back to the maintainer, then my own problems are solved within minutes--but if I don't send the patch back to the maintainer, then I have to support the patch myself, and I don't want to do that.
Of course in discussing this we are in danger of falling into the trap of discussing classes instead of instances. There is some commercial software out there that is significantly worse than no software at all, and there is some commercial software that GNU is a long way away from imitating, let alone surpassing. There are exceptions to every rule except the rule with no exceptions.;-)
However, it's a myth that you have to actively participate in the development of all GNU software products that you use. You will have a much better experience with the product if you do participate--even if you do nothing but report bugs, remember that someone might fix some of them for you--but it's not essential. Exactly the same thing can be said of commercial software--using the 1-800 tech support numbers may help but is not necessary.
Corel people are reading Slashdot. There's me and at least one other person who are Slashdot regulars, and not just the "Corel" section of Slashdot either.
Slashdot Mirror
Aside from 'make -j2', which schedules multiple independent Make targets for concurrent execution, there is also 'gcc -pipe' which implies at least two processes.
There is a wall-time improvement just doing a "straight" (no application-level SMP support) compile of a large program such as the Linux kernel on a two-processor machine.
I think the first goal is to get Linux/i386 working, given that that's the easiest target for a port from Win32/i386 code that assumes sizeof(void*)==4 and little-endian byte order. Gotta walk before you can run. If you really want a PPC port, I suggest you start with the win32-compatibility library in Wine.
I've heard rumors that one of the Linux team has successfully made Wine (at least the source compatibility library portion of it) compile on Linux/PPC. It probably doesn't work due to the big-endian architecture, but it links without error. I have heard no rumors about anyone trying to make Corel Draw compile with it though.
Other rumors: the people on the team have access (either at home or at work) to Linux/Alpha, Linux/PPC, and Linux/strongARM. The team was derived from the Mac port team, so they have plenty of PPC hardware to test on.
GNU software is always better than commercial software _at the same level of maturity_.
;-)
Don't bother trying to compare ten year old commercial applications with GNU applications that have only existed for two years and have only been usable for half that time. The commercial software will usually (although not always) win such a biased contest.
Almost all software projects, commercial and GNU, have differences, and depending on the user's needs one will always be "better" than another. GNU software tends to be rich in documentation (the problem with Linux is not lack of documentation, it's way way way too much documentation in too many places), capability (features that are possible, but not necessarily implemented), extensibility (if there's no plugin interface, write one), reliability (doesn't crash) and portability (it's easy to be GNU-compatible).
These are all important to me, and over the last six years of using Linux I have learned that it is so unlikely for commercial software to provide this at a reasonable price (i.e. less than US$50K) that I no longer waste my time evaluating any kind of software for my personal use unless it comes with complete source code.
Commercial software tends to be rich in features (capabilities that have been implemented) and stability (doesn't change), and comes with bundled non-software products (such as hardware, technical support, and some kind of warranty) and obscure kinds of compatibility (usually with itself and its major competitors only, though). Note that it is possible to get all of these things from a vendor of GNU software, so these are not very large advantages for commercial software.
These are not important to me and some of them are actually drawbacks. For example, consider the amount of time and money required to characterize a problem in commercial software (which inevitably involves some reverse-engineering of the software because there is no source code to use as a reference), wait for vendor customer support, communicate the problem to the support person, communicate it again when they realize that they can't solve it on their own and have to get a technical person to handle the call, justify the business reasons for the solution to the problem, execute a contract for delivery of a fix to the problem, wait for delivery, verify that the delivered fix corrects the problem (which is not a 100% probable event I assure you), and pay for the privilege of doing all this work (which in some corporations is a chore in and of itself). We are talking about weeks here.
Now consider the amount of time required to characterize a problem in GNU software (less, because I can walk through the source code and see problems immediately), create a patch that fixes the problem, test the patch, send it to the product's maintainer, and have a new release of the software available to the general public. When I find and fix a bug in OSS, it's fixed _immediately_ and _forever_. We are talking about hours here. If I skip the parts about sending the patch back to the maintainer, then my own problems are solved within minutes--but if I don't send the patch back to the maintainer, then I have to support the patch myself, and I don't want to do that.
Of course in discussing this we are in danger of falling into the trap of discussing classes instead of instances. There is some commercial software out there that is significantly worse than no software at all, and there is some commercial software that GNU is a long way away from imitating, let alone surpassing. There are exceptions to every rule except the rule with no exceptions.
However, it's a myth that you have to actively participate in the development of all GNU software products that you use. You will have a much better experience with the product if you do participate--even if you do nothing but report bugs, remember that someone might fix some of them for you--but it's not essential. Exactly the same thing can be said of commercial software--using the 1-800 tech support numbers may help but is not necessary.
Corel people are reading Slashdot. There's me and at least one other person who are Slashdot regulars, and not just the "Corel" section of Slashdot either.
Netscape crashing will not always bring down NT.
The fact that Netscape crashing can bring down NT is sufficient to make NT impractical.