Slashdot Mirror
Why Port from UNIX to OS X?
mblase asks: "According to a recent MacCentral article, one of the benefits of Mac OS X's NeXT-based roots is that "since Mac OS X is BSD based, the ports shouldn't be too difficult. The hardest part, according to Robert Palmer, will be writing the GUI (graphical user interface) front end to make administration easy." My question is, is this likely to happen? Will UNIX developers want to port their applications to an operating system that costs more in hardware and OS software both? Or is the demand likely to come from the other direction -- OS X server admins who want the stability and popularity of established UNIX applications, even if the graphical front-end Mac users have come to expect may be less than ideal? This will doubtless be a big issue for Apple as they tout Mac OS X as a server platform for the future."
nik says: How about "larger installed userbase"? Assume Linux has ~ 7 million users, and the BSD's have about 3 million (both those numbers are on the conservative side). Apple's probably going to ship 10 million or more OS X boxes in the next year or so, and porting most software is going to be no-brainer (particularly if it's already in the Free, Net, and Open BSD ports and packages collections).
It's not really interesting to port "Unix apps" - in the sense of command-line sysadmin software - to OSX. (Mac-based servers will probably be running OSX Server, which resembles NeXT even more and, when you get down to it, is a full-fledged *nix in all but the name. Porting to it should be trivial.)
:)
What's really interesting to port is what we more often think of as "Linux apps" - stuff that you usually run under Gnome or KDE. Galeon is a good example, as are Gnumeric and LyX. This is graphical end-user level software. There is really no good reason not to port it to OSX; in fact, I plan to do some porting myself once it's released. The only significant obstacle I can think of is the graphics toolkit; with that in mind, I think it'd be interesting to begin a project to provide compatibility layers for all the common graphics toolkits - GTK, Qt, Tk (as in Tcl/ or Perl/), and so on - under OSX. Having that, porting your average "Linux program" to the new system would be almost trivial. The programmers in charge would have a much-expanded user base; and the users would be able to run just about anything that shows up on Freshmeat.net. Everybody's happy
To the editors: your English is as bad as your Perl. Please go back to grade school.
Dual 500MHZ G4 - $3,499
MAC OS X - $500
Apple Cinema Display - $3,999.00
Being able to Kill -9 that fscking crashed quark session - priceless
-Spazimodo
Fsck the millennium, we want it now.
Fsck the millennium, we want it now.
Millennium Crisis Line: 0890 900 2000 [calls cost 50p/min]
Last I heard, Apple was still planning to include some sort of command line interface for "Advanced Users" if they wanted to install it. How hard would it be to set up an option in the installer for "command line only"?
This is so completely pointless. Even hardcore loons can see the advantage to having a bunch of shell windows open at once as opposed to virtual terminals in a "text" mode. To answer your question, fullscreen apps are fine under Aqua, so there's no reason somone couldn't whip together a fullscreen shell interface.
To all the wannabe hacker types who hate Aqua: Stop acting like it is going to cramp your style. You can live in a terminal window if you want; just maximize the window. Then, as a bonus, if you really need to do something graphical, like browse the web with something other than Lynx, you can do it, no fuss. Please stop acting like simply having Aqua on your machine is going to make you unproductive. Even Linus doesn't work in a text-only mode any more. And you *will* need graphical applications now and then, even if just to look ar pr0n.
When did Robert Palmer become a developer?
(I'll bet he sits at his keyboard, and has like 10 identical female dancers dancing in sync behind him while he's writing code.)
Hmmm, That would actually be kinda cool.
-- Give him Head? Be a Beacon?
-- Give him Head? Be a Beacon? :P)
(If you can't figure out how to E-Mail me, Don't.
the mac-bashing just amuses me. :)
1. "How can you compare an iMac to a RISC machine?"
Answer: An iMac is a RISC machine (PowerPC), if the distinction even matters anymore. Ever seen a G3/400 whip the crap out of an SGI O2 on FPU performance? Try it sometime.
2. "Apple is losing the MHz wars!!"
Answer: Try learning something about computers. Call me when you figure out how meaningful MHz is.
3. "The iMac is too puny to run OSX!"
Answer: The iMac can run up to G3/500 with 512M of RAM and as big of a (ugh, IDE) disk as you want. And it does run OSX DP4.
4. "But you have an iMac, so you're obviously stupid."
Answer: No, I have four iMacs, all running LinuxPPC. Get it right.
From www.gnustep.org:
GNUstep provides an Object-Oriented application development framework and tool set for use on a wide variety of computer platforms. GNUstep is based on the original OpenStep specification provided by NeXT, Inc. (now Apple). GNUstep is becoming more and more stable every day and is used in a production environment by several companies.
Disclaimer: I have not seen MacOS X from the inside. I have seen Nextstep from the inside. It was beautiful.
Nextstep had one of the easiest and most elegant programming languages I have ever seen. It was called Objective-C and was OO in C done right: Pure C with the Object mechanisms of Smalltalk thrown in. You might have seen part of the ideas behind Objective-C recently: The signal-slot mechanism in the Meta Object Compiler (moc) in Qt has its roots in the Objective-C model, and Gtk ported that to plain C. In Objective-C it is part of the language, no moc or handcoding necessary, and all objects, slots and method invocations use this mechanism.
On top of this, the Next people built an API and tools which really revolutionized programming for me. This was the only programming environment where I actually felt supported by the API and programmed to solve a problem, instead of fighting shortcomings of the system.
The OO toolkits that came with their Objective-C compilers were one of the most cleverly designed collection of classes I have ever seen: By combining components of the Appkit and the Enterprise Object Framework, I was able to built applications which navigated a system of SQL tables, browsed tables and even allowed simple changes in table values in the SQL database - and I was able to do this by simply connecting the components in Interface Builder, no compile necessary for a working application! Of course you could compile and save the result and had a standalone application which worked just as well.
But Nextsteps Objective-C objects had enough metainformation ready that they were loadable and runnable (sic!) in their equivalent of Kdevelop. This is was reusable component software done right can do for you. Talk about fragile superclasses, about Corba and COM. I had all this in 1994, on a 25 MHz 68040 with 20 MB RAM, and it was better than anything that money can buy now.
On top of this, Nextstep delivered a GUI which painted every single pixel on the display with a postscript interpreter. This allowed you to write widgets in postscript, load them into the (possibly running remotely) display server, and run them with a single command. In todays buzzwords that would be equivalent to writing all your widgets in Java, uploading them to your X server once, and have them running up there, instead of sending four million drawing commands each time your want your widget shown. Nextsteps GUI displaying remotely was faster than X even with compression on slow links, because "execute that widget again" is faster to transmit and parse than all these drawing commands, and "your button 17 has been hit by left-mouse-down" is faster on the wire than long lists "mouse-move to coordinates x,y", "mouse-down on x,y" events.
The fact that postscript can do coordinate transformation, font handling, color, alpha channel mixing and several other things right which X still cannot do properly today helped, too.
But enough of the nostalgy. Here is my advice to you: Have a close look at MacOS X native API, at the language, at the object system, at the display system and at several other things. The Next people are extremely bright, and they are still at work at Apple. Unless Apple managed to really fuck up their Nextstep heritage, you have the chance to see a really, really nicely engineered system and you may learn a lot of things about elegance of design, about handling software components, and about OOP outside the scope of C++ and Java.
Do not try to port your code. You won't be doing your code and the MacOS X API a favor. Make your first experiences with natively designed code, and try to forget your Unix and C++ heritage when you make them. Unlearn what you have done previously and relearn programming and OO their way. Try to see the beauty of their way and widen your perspective.
Then come back and review your old work in your newly collected experience. I will find that your have many new and exciting ideas what to do and how to do it differently.
© Copyright 2000 Kristian Köhntopp
This is true of the OS, but I doubt that it will be formally enforced with apps. However, I think you are on to something here.
Just as the UNIX culture has an ethic of doing the Right Thing when writing software, mostly centered around maximizing efficiency and portability of code, the culture of Mac gurus have very strong opinions about well-designed code, particularilly in the area of making your user interface logical, simple, and seamlessly consistant with the conventions of the MacOS.
A good example of thier fury was MS-Word version 6.
In spite of the massive hatred of DOS and anything else to do with Redmond, Word 5 was the most popular word processor for the Mac ever. It had been, since the very first version, designed specifically for the Mac, and clung tight to the reccomendation the of GUI cannon that was coming out of Cupertino throughout the late 80's and early 90's.
When M$ came to version 6, they decided that what Mac users really wanted was interoperability with the Windows box they had at work, so instead of adding Word6 features to the Mac version of Word5, they did a crufty port of Word6 for Windows to the MacOS, complete with Windowsy dialog boxes and button bars. Some of it even used the old windows code, with translators copied into the Mac system folder during installation. Even the Word Macro viruses were cross-platform transparent.
The backlash was epic in scale.
Macophiles ourtright refused to "upgrade", and if they did give up their Word5, it was to switch vendors to Word Perfect For Mac or Nissus Writer. Some of them even switched to heavy-duty page-layout apps, like PageMaker or Quark, rather than deal with the steaming pile of crap that Word6 was quickly discovered to be.
Microsoft eventually recovered when they release Office98, but only because they are Microsoft. A small company that made such a huge misstep would probably never be heard from again.
My advice to *n?x vendors who want to reach a wider audience by porting their C app to the Mac platform would be to either bone up on Mac GUI conventions, or else perhaps contact a MUG and find a Mac code geek who is willing to work with you on it.
Information wants to be anthropomorphized.