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."
that Apple in general isn't propagating that their stuff is better than XGF-productname.
but Apple is embracing it.
i think that many more fortune-500 companies could take a few hints
from Apple & IBM's marketing ideas & schematics..
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.
Isn't X-11 already available either on the mac-install disk and as part fo fink. Or are these just X-11 servers instead of being real cleints (using the bass-ackward X-11 speak)?
Some drink at the fountain of knowledge. Others just gargle.
I should try submitting "Apple posts technical Q&A on variable arguments in Objective-C methods" as a slashdot article, if every update to the ADC website needs its own story.
Don't blame me; I'm never given mod points.
X11 is the protocol. XFree86 is the implementation that nobody likes anymore due to the change in license. X.org is the implementation that everyone is moving to. There are a number of other implementations.
Apple committed to XFree86 long before they changed the license. They may move to X.org as that implementation gets better features.
I rarely criticize things I don't care about.
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.
What they need to do is write a simple extension to their version of X11 that allows X11 applications on the Mac to have their own Dock icons. Even if it weren't backward-compatible, a lot of projects like OO.o would quickly move to implement this. If they made a standard to embed X11 programs in .app form, it would be great for many applications. Obviously you wouldn't want everything this way, but many applications would benefit. Combined with quartz-wm, such a system would allow such a completely transparent integration that less advanced users would find it unnecessary to distinguish between Cocoa/Carbon and X11 apps. This and a little bit of polish could make certain projects like OO.o take off on the Mac IMHO.
English is easier said than done.
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?
Some compilers require an explicit "-ansi" switch to properly compile ANSI code. HP7v8 requires the magical compiler flags "+DA1.0 +DS1.0". On Solaris, we need to add a "-Xc" flag.
The situation is complicated by the fact that we do two Solaris builds. One build is done with the native compiler, the other uses GCC. As you might expect, these require slightly different flags.
Some platforms need a "ranlib" program to build the library indexes in the .a files. Some platforms have this functionality built into the ar utility.
On Solaris, we need to link against libsunmath.a instead of the traditional libm.a. Solaris also required linker flags "-lw -lresolv -lsocket -lnsl -ldl", other platforms do not.
Don't even get me started on the difficulty of doing static/dynamic builds (we do both types) on each of the various platforms. Some of the platforms have GNU binutils. Some do not. Some are remote. Some of the platforms we compile on don't even BELONG to us (we build on the customer's system).
Did I mention that this thing works on VMS and OS/390 also? And that it depends on Motif?
Hey!
That's it!
Funny thing is I had enabled the Windows Sharing in that same dialog earlier to get samba working, and i hadn't noticed that ssh was in there.
Actually I didn't expect something as arcane as ssh to be so simple, but that's Mac for you.
I just received this machine (A G5 Powermac, the 64 bit one with dual processors) and I can see I still have a bit of "unlearning" to do.
Thanks thesman, very kind of you.
I don't know the meaning of the word 'don't' - J
You do know that under the old "SimpleText" app from the System 7 days would speak text for you.
"vi" was actually pronounced as "six".
--
The internet is the greatest source of biased information in the history of mankind.
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!