Slashdot Mirror
Apple Explains How to Run X11 on Mac OS X
tuc writes "In this document posted on its Developer Connection, Apple explains how to install X11R6 on Mac OS X, details of the default quartz-wm window manager, how to compile X11 code on Mac OS X, how to install OpenOffice, and the like."
I think I'll wait to RTFA until after I've tried everything on my own first. Nothing like thrashing randomly to help you learn about a system :-)
Believe me, you do not want to see what the Makefiles for a piece of software like that look like. We're talking about the era before GNU-style "configure" scripts and Makefile modularity. It's hideous. But it works. And it makes the differences between the various UNIX platforms as clear as day.
Right now, I'm in the middle of porting our main project to run on OS X, so this article is very timely. To be honest, I anticipate that the majority of the difficulty will be in getting the make system to run correctly, and possibly fixing a number of linker issues. I expect that the code itself will work almost unmodified.
Apple's X11 implementation is based on the widely-used XFree86 project
Is apple going to switch to X.org, since most everyone else has already? or are they sticking with XFree86 for the long run? What kinds of compatibility issues will develop as a result of that?
I rather like how the instructions talk about how to run X11 remotely, and the first thing they do is tell how to do it over ssh, with simple, easy to understand directions on how to do it. That is how "how to" manuals should be written.
2 points to Apple for doing that, and making my coworkers jobs a little harder (they're penetration testers).
52 Weeks, 52 Religions with John Hummel
You pigeonhole them too much.
As of OS-X, there is a *LOT* of interest in Apple systems as engineering workstations. That's what I'm using, as are many people I know. This mac replaced my linux box at work.
The big interest in Macs as engineering workstations isn't exactly a big secret.... anyway not to anyone in the engineering field.
Yes, there are also plenty of other platforms used. Still a lot of Sun/Linux/other boxes here as engineering workstations, and that isn't about to change in the near future. The Macs aren't suddenly taking over it all - but they are certainly now a significant player in that market.
I think you're over-estimating the animosity between MS and Apple, if indeed there's much at all.
Of course, they compete with eachother, but what you describe doesn't sound like my interpretation of Apple and MS's behaviour.
The Macintosh Business Unit at Microsoft have a very close relationship with Apple. They're not just some MS developers who've been told to bash out some Mac knock-offs of Windows software. They're all long-time Mac developers who want to make the best Mac software they can. The spin-off of the MacBU to a separate division meant that they could work on making Mac software, not Windows ports. As this article explains, before the creation of the MacBU, the Win & Mac versions of Office shared 80% of the same technology. The result? Shoddy, un-Maclike software which no-one liked and few bought. The MacBU now works every bit as closely with Apple's technologies as it does with MS's.
Office:Mac (both v.X and 2004) are very nice programs. They're not perfect, but they bring a very usable, feature-rich, Mac-specific Office suite to the platform.
Apple would not benefit one single bit from making the MacBU's software unprofitable for Microsoft. iWork is not a replacement for Office. Keynote's a very nice alternative to PowerPoint, sure. But one app does not an Office-suite make. Pages is clearly not in the same space as Word. If you need Word, you won't buy/use Pages. If you don't need Word or can't afford Office, Pages is a sensible choice. If Pages is aimed at those who don't need or won't buy Office, it's hardly a competitor, is it?
Just as Pages is not a drop-in replacement for those who need Word, any rumoured spreadsheet app will not be a drop-in replacement for those who need Excel.
Apple aren't in the business of making 'temporary, difficult alternatives'. They're about fulfilling user's needs (with the caveat that, like all corps., they don't always get that right!).
What's the frequency, Kenneth?
I've done this sort of thing before - had to have things that run under linux, Irix, SunOS, and windows. It's not really hard as long as you start out with the idea that things are going to be system-dependent. I had directories with Makefiles in that called directories (some ours, some 3rd-party) Makefiles etc. etc. You just need to put the thought in ahead of time.
/. these days leads me to believe I've become an old fart. Oh well. Happens to the best of us [grin]
My solution was to have the top-level Makefile set a variable based on running the 'uname' command, and then 'include' the definitions that worked for the platform, based on the variable name (we were running gcc and gmake on all the platforms, although the windows one was cross-compiled under Linux. Believe it or not, this was easier!)
So, CC, CXX, JAVA, LD, RM, AR, RANLIB
etc. etc were all defined within the platform-specific file, and the main Makefile looked pretty clean. All you have then are the #ifdef statements in the source code. It did get to the point where for one project we simply had different source code for the Windows variant, and the platform-specific Makefiles copied the correct file into place before trying to compile the module in question...
Looking back at the posts I'm making on
Simon.
Physicists get Hadrons!