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).
iMac: ~$799
Cheapest new Sun workstation: ~$2000
Draw your own conclutions. The Macintosh will be the cheapest and most available system ever to come with a UNIX preloaded. No other UNIX-like platform alone will match the cost and installed base of the Macintosh. Port? You betcha. Why do so many people port to NT? Porting to OS X is even easier than porting to NT. Win for Apple.
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.
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.
OK, I'm not a super-coder but from my own understanding (and a slashdot article earlier thatn addressed these issues) I'd like to point out that it's a very unfair assumption to claim that GUI porting is easy.
/. article suggested (or at least the comments did) that if M$ released IE for OSX that IE could be ported to X. Not quite.
The earlier
In order to port over a GUI application, you first need to port the graphics libraries and other libraries, which more than likely aren't going to be Open under OSX (correct me if I'm wrong).
If it can be done, I question what software is going to get to OSX. Most good software, IMHO, already has a *nux port (or was designed for Linux *grin*), or has at least planned on porting it. Sadly, it's been my experience that a lot of people (especially the suits I work with) are loath to give up Winblows because of IE, Office, and other memory-hoggin' applications. If it turns out apps can be ported from OSX to *nix rather easily, then my bet is on M$ not writing any software for OSX.
IMHO, this is the exact same reason M$ doesn't make a Linux distro; to do so would require them to open a least a bit of their code, and M$ is scared shitless of the opensource community being able to run their programs/derivatives without paying ungodly liscence fees.
I think the best alternative is not porting over software that companies won't release themselves; rather, we need to let people know we have something better. Porting M$ software and other software that snubs the *nix world does us no favor; it simply tells these companies that their product is so "good" we need it and will port it ourselves. And hell, if the company doesn't like it they can always file charges.
While I admit it would be nice to be able to run every game than runs on a Mac (not sure on the OSX gaming specs) I think we should move towards developing programs designed to run on *nix, not porting over from other OS's. As we continue to grow, companies with enough sense will put out *nix ports. If not, their loss.
Peace,
DranoK
That is not dead which can eternal lie, and with strange eons even death may die.
Shh! Nobody knows I'm gay!
Here's an example showing tar and gzip in use.
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.
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
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
Apple has designed a good client machine for non-technical users. It may also work in some server and engineering applications. But let's not pretend that it is something that it isn't. Different people and applications have different needs, and if you optimize a design for one application, it will often be suboptimal for others.
Anyway, my rant on the issue is that sites like MacInsider are touting the fact that the Mach kernel "Has been forged in the fire of open source peer review, etc.", but then they're ripping it out of the open source community and making it proprietary.
I'd rather have someone respond than be modded up.
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.