Will MacIntel Hardware Open The Door for Mac OS X CAD? 126
xcleetusx wonders: "I've been a fan of Apple for years, and with their current strangle-hold on mainstream media my desire to make the switch has been growing ever more, but the same nagging issue that has prevented my switch for years still remains: I'm an engineer, and I simply can't invest in a computer that won't run modeling/simulation software like CATIA and Solidworks. Since this software is available on Unix (which Mac OS X is built on) and also on Windows (Intel hardware), is the Apple switch to Intel-based hardware going to better my chances for a Mac OS X CAD workstation, or will it remain a pipedream?"
Say it with me (Score:5, Interesting)
Since Mac OS X will use a Darwin (Unixish) on x86, it will not be very hard to port your standard CAD programs to run natively in OSX. Mostly it depends on the demand in the market. If a lot of users start asking the CAD software developers for a port to OSX, it will probably happen. Short of that, your best bet may be Darwine or X11 for OSX. Using one of these may allow you to run standard CAD software without it actually being ported (don't hold your breath for Darwine, though).
Re:Say it with me (Score:4, Interesting)
Why not? Besides the fact that you'll pass out, fall down, and start breathing again. The only thing really holding up Darwine is the emulation of the processor being tied to the API's. You have to get an x86 emu installed, tweaked, then install something that's not always entirely stable to begin with on top of something else not entirely stable.
The original post is asking how the move to Intel will affect CAD software. I say any CAD software that is written for a *NIX on x86 will appear very quickly on MacTel. WINE, being what it is, will probably be available for MacTel on day 2. They will no longer need to emulate the x86 hardware, it's already there.
In fact, I predict someone in the Open Source community will completely side step the issue anyway and develop a Mac-On-Linux (MOL) like system "hole." MOL allows Mac Linux users to continue to run Mac OS X within Linux by giving it control of the underlying hardware resources. Better than Virtual PC, and probably what the Virtual Server product Microsoft is talking about does. I also know there is something on Linux (that I've never used so don't remember) that allows something similar in running multiple Linux instances on a single hardware set.
What ever bad things the MacTel moves brings with it, the good is in the instant tripling of software that will be available. Whether it be through WINE, or WOM (Windows-On-Mac) (hey ... WOMBAT ... now what can the BAT stand for), or Virtual PC, or straight up multi-booting. MacTel is looking good.
If nothing else, I regularly SSH into a linux machine next to my current PPC Mac and push programs to it via the X11 protocols. This won't change no matter what the underlying hardware is, so worse case scenario is two machines. One Mac desktop and One Massive *NIX box. (I'm thinking rack mounted Solaris might be fun) and you're set. The great thing about networking is you don't need to run *everything* native. Let something else do the work and push the visual to you through ethernet.
But everyone here already knew that, right?
Scientific Programming is HARD HARD HARD. (Score:3, Interesting)
MacOS is not going to magically turn into Windows or Linux just because there's Intel Inside. Mac development will be unchanged, with some marginal exceptions.
I dunno, maybe this falls into the "marginal" category, but "scientific" [or "mathematical"] programming is really REALLY REALLY difficult.
For instance, take a gander at the list of FFTs catalogued at BenchFFT:
Then look at their relative performances for speed and accuracy: In many instances, the software and hardware engineers at the companies that build the chips [Intel and AMD] can't write FFTs that are as efficient as third-party vendors [or hobbyists], which should be a pretty good indication that something as ostensibly straightforward as writing an FFT routine is just fantastically complicated in practice.So if you're a company with a lot of low-level proprietary software that's tuned for the x86/x86-64 instructions sets, or for classical PCI bus communications [apparently PCIe is very backwards compatible], or for the nVidia/ATI/Oxygen instruction sets, then your porting job just got a heckuva lot easier if you don't have to deal with PPC RISC, Altivec, etc etc etc.
Re:No (Score:3, Interesting)
"No" what? No, there won't be increased demand for OS X native software if there are more OS X users? No, there won't be more OS X users because they have the comfort-option of dumping OS X and running Windows? No, developers won't have a potentially easier time porting apps and such to x86 OS X than PPC OS X?
And you're a fool if you think fewer apps will be ported. Right now, very few apps are ported at all. None of those companies are going to *not* maintain their port. Adobe isn't going to say, "Well, just run the emulated Windows version".
Unlike OS/2 (which you *might* be thinking of), OS X will not come with Windows compatibility built-in. You'll have to buy that separately. So if a software publisher wants to target the Mac (which is more likely given more Mac users), they can't just rely on emulation.
Unlike OS/2, the Mac market in non-vertical environments is not insignificant.
Unlike OS/2, Mac native apps are significantly preferable to emulated apps.
Re:...stop thinking autodesk (Score:3, Interesting)
Of course, I could have done the same thing in any 2D package, so long as it supported a full programming environment. So I guess it wasn't that specific to AutoCAD.
Re:...stop thinking autodesk (Score:3, Interesting)
Re:No (Score:3, Interesting)
Because developers who are interested in cross-platform sales already make Mac versions -- they know they'll lose customers if their app no longer has Aqua effects and built-in spell checking and other things Mac users expect.
Developers who don't do crossplatform, well, some of them will say "great, now I don't have to worry about it since they have VMware!", while others will say "great, now I can do cross-platform a lot easier!" I think in the end, more software will be developed for the Mac because the number of small developers who are curious will be much greater than the number of large companies that are trying to shave money from the budget.
And keep in mind the Mac, as it is now, is a niche market anyways. Companies don't need an excuse to stop developing for it if, they either find that they are making a lot of money from it or they go after the 90%+ that are running Windows.
Re:Only hope lies in increased popularity. (Score:5, Interesting)
On OSX it is. In fact, it's the antithesis of everything the Mac UI stands for - it's clunky, enigmatic, and difficult for people who aren't familiar with it to troubleshoot.
My girlfriend gave up on using openoffice altogether because of X11.
While I don't argue X11's potential, its implementation on OSX leaves much to be desired.
Why will the switch help? (Score:3, Interesting)
They already support AIX on POWER and PowerPC. Given that they haven't ported a program that runs on AIX/PPC to OSX/PPC, what makes you think they will port a Win/x86 program to OSX/x86?
It's not about obscurity. CATIA runs on platforms with tiny marketshares like HP-UX (on PA-RISC?), Solaris on Sparc, and IRIX on Rx000. The software is obviously very portable, DS just has no interest in an OSX port.
I'm a huge fan of CATIA (just reupped my license a week ago
Re:Hardware OS (Score:1, Interesting)
What you want is to be able to run the Unix version of the app natively on your Mac and that's what Linux binary compatibility will do.
Yes, users want to run apps natively, but running from the command line or X Windows is not good enough.
To blend in with the system, it must look and feel like a Mac app , not only superficially. Users will expect such things as:
In short: users want a Mac app. If they were happy running a Linux app, they would be running Linux already.
Architosh... (Score:1, Interesting)
http://www.architosh.com/features/2005/features/a