Slashdot Log In
Why Port from UNIX to OS X?
Posted by
Cliff
on Thu Jul 27, 2000 12:52 PM
from the stuff-to-think-about dept.
from the stuff-to-think-about dept.
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).
This discussion has been archived.
No new comments can be posted.
Why port from UNIX to OS X?
|
Log In/Create an Account
| Top
| 289 comments
(Spill at 50!) | Index Only
| Search Discussion
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Haha! (Score:3)
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.
Not your garden-variety Unix apps (Score:4)
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
Re:Haha! (Score:4)
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.
Re:Command Line in OSX (Score:5)
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.
Problems... (Score:3)
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.
Re:Command Line in OSX (Score:3)
Here's an example [apple.com] showing tar and gzip in use.
Developer? (Score:4)
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?
it's fun, but... (Score:4)
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.
And with GNUStep you can keep your software free! (Score:4)
From www.gnustep.org [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.
Re:What is there to port? (Score:3)
--
Don't port. Write. You'll learn something. (Score:5)
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
Re:Command Line in OSX (Score:3)
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.
Why not call it... (Score:3)
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.
Re:UNIX guys dont need GUIs (Score:5)
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.
Re:Not your garden-variety Unix apps (Score:3)
Jesus, I hope they won't be running by default! We bitch about this enough regarding Linux, but even Red Hat or SuSE requires a bit of tinkering with the installer, so if you've gotten as far as getting it installed you might as well turn off all those pesky unneeded daemons. Now, ten million or more OSX-using newbies who don't even know enough to run the Process Manager and see ftpd, httpd and whatnot running, let alone know what they do and turn them off... that'll be a script kiddie's paradise.
Re:Don't port. Write. You'll learn something. (Score:3)
OpenStep on a PC was by far the slowest Unix (compared with other Unices on the same hardware) on the face of the earth. I don't know why this is; some say it's the fact that all windows were buffered, some think it was microkernel overhead. It's really hard to be slower than Mac OS 9, with it's gulag of partially native/partially emulated I/O paths, but Mac OS X DP4 manages it . This may improve by the public beta or the final release.
Combining a mediocre GUI with an obsolete version of Unix isn't going to help the average Mac OS consumer. It will help developers, however. If you have a lot of RAM, OS X will be a great developer system.
Try to see the beauty of their way and widen your perspective.
I'd be more impressed if "their way" had a provision for error checking.
Objective-C has an (arguably) annoying syntax, limited type checking, no access control and lacks exception handling. If you can get past those limitations, it's a really easy and kinda fun language to use. It also happens to be pretty much useless for anything other than programming Cocoa apps. What I'd like to see is Java compiling to native PowerPC code.
color, alpha channel mixing
A nit: These were proprietary extensions to the display postscript server, not part of PostScript proper.
All of that said, the CoreGraphics engine behind the Aqua interface is a giant leap forward. Makes Aqua all the more shameful, since Apple could obviously do so much better in UI design, if Steve cared at all.
Re:Don't port. Write. You'll learn something. (Score:3)
In Nextstep, all drawing was offscreen, in regular memory where the Postscript interpreter could access the bytes. These buffers were then downmixed to the appropriate depth and blitted on screen in this process. That is, if you had a 12 bit display, and a 4 bit display attached to your system, all drawing was offscreen in 12 bit/pixel, and then blitted out on the screen, possibly downmixing the color to the target display. This requires much RAM. If you took care to add enough RAM to the machine (I had a Nextstation with a 2 bit grey display and 20 MB, others had a 12 bit display and 32 MB), it was actually quite fast.
Comparing a Quadra and a Nextstation (same CPU, same clock, same amount of memory - 68040@25 MHz, 20 MB RAM), both using the same version of Illustrator and the same image, side to side, the Nextstation won hands down, due to superior memory management and better drawing subsystem.
Objective-C has an (arguably) annoying syntax, limited type checking, no access control and lacks exception handling.
Objective-C is all about component software. Components may even be added to finished programs as NSBundles or other form of dynamically loaded packages. To facilitate that, as much typechecking is deferred to runtime in Objective-C. Qt and Gtk do the same, for the same reasons, and so do Corba and COM: There is no way to use static typing (compile time typing) in component software.
Objective-C is typed, though, but it is dynamic typing (runtime typing). You can ask anything, anytime, what type it is and it will tell you its class and methods. You can ask objects "can you perform a 'xyz' method call, if I asked you to do this?" and the object can answer this. As I said in my initial posting, this is very different from C++ and Simula, it is Smalltalk. And it is really important for component software development.
As for access control: I don't believe in it. As soon as "private" and "protected" were invented, people were crying for "friend" to work around it. Access control is more a social problem ("We do not want to use these method calls, as they are private and can change anytime"), and as most social problems there should not be a technical solution for it ("But I really need to call this internal function, or I won't have code" "Then do it, and face the consequences when we upgrade").
And finally: yes. Objective-C has no builtin exceptions as Java has. It has a set of macros that basically do a try/catch block, even in a similar syntax (just all upcase, as these are macros).
These were proprietary extensions to the display postscript server, not part of PostScript proper.
These were no more propietary as postscript itself: Next bought the interpreter from Adobe, as all people did. They just got a newer version as for example what was shipped with the Solaris X server as an X extension.
© Copyright 2000 Kristian Köhntopp