Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Apple Businesses

Why Port from UNIX to OS X? 289

Posted by Cliff 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? More

Why port from UNIX to OS X?

Comments Filter:
  • first - i think they've announced that server and "consumer" versions won't be seperate after they actually release the consumer version. second - there was a port of X announced the other day... so why would you really _need_ to redo the UI? as long as it runs, it runs. if a whole lot of people like it after you recompile it, then worry about the front end. possibly a better idea is to port QT or the GTK?

  • Haha! (Score:3)

    by 11223 ( 201561 ) on Thursday July 27, 2000 @08:57AM (#900226)
    Will UNIX developers want to port their applications to an operating system that costs more in hardware and OS software both?

    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.

  • The point of MacOS X is to have the robustness of Unix (vs. the older primitive floppy-based kernel) with the "user friendliness" of the Mac. Sounds like a good deal to me, if you're looking to attract the types of people who favor Macs (and who by inference generally wouldn't be comfortable in a classical Unix environment).
  • Like the article says, what would the advantage be for porting it to OSX...The only one I can think of is the availability of some Macs...I know at my old job, we had a ton of macs that were useless because they did not have the software on them that was needed...I could see putting Unix on it and then having use for them again and saving a little money.
  • "The hardest part, according to Robert Palmer, will be writing the GUI..."

    This is old news. Haven't you ever heard his song? "Simply Unportable"

    As for "assume Linux has 7 million users"--there are more than that. That figure comes from a survey done 3-4 years ago. The other conclusion of that study was that the numbers were doubling every year. Even assuming it's still "only" doubling that puts us at 54-108 million.

    That number seems a little high to me, but that's just a gut reaction. Don't bother responding with YOUR gut reactions--get some hard facts (or at least hard reasoning).
    --
    Give us our karma back! Punish Karma Whores through meta-mod!
  • Who will do the porting depends on who is doing the developing. Commercial developers seek users for their software, they will be more likely to be the ones porting their product to the OSX platform, in order to increase market share, gain users, so forth. Open Source Software, however, is the development of software in order to fill a need, it is open sourced to share with the world. People who want OSS on their system typically do the ports themselves. The developers of the software generally aren't looking for more users, it is users looking for the software, and hence they usually do the porting. There are of course, projects such as NetBSD, who really want to run on every platform in existence from supercomputers to gameboys. Overwhelmingly, who ports the software will depend on who owns it, why it is being ported, and who wants it.



  • 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"? They already have Darwin, which is command-line only, so apparently it's possible to separate the Aqua prettiness from the command line. I think if they offered this option it would please a lot of the server admins out there and would increase OSX's viability as a server platform.
    -colin

  • MacOS X (Score:1)

    by xinu ( 64069 )
    I as a Solaris Admin and a BSD fan. I wholeheartedly am gonna be jumping on the Macintosh bandwagon. I love the idea of a creamy outside with the crunchy inards. The GUI's have always sucked in UNIX but have been stable. I have always just used a terminal windows for the most part for a CLI anyway. I think it's a great combo personally and love the immense power of the G4's. I wish I had come up with the idea myself... But anyhow, I plan on supporting it and doing my share of development and porting.
  • 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 :)

  • There will be two camps of OSX users. Some GUI only mac faithful, and some more sophisticated users like developers, service deployers and "power users". The latter camp will benefit from shell based, unix command line tools, without any further UI work. These tools should port for almost no work. Then there can be a lot of convergence work between the OSX community and the Unix community, where experienced cocoa developers can build Cocoa front ends to unix originated tools/libraries. The combined results will not flow back to Unix, but live exclusively in the OSX world. In fact, this situation already exists with OpenStep/YellowBox. One (of many) example is CVL, a Cocoa front end to cvs (http://www.sente.ch/software/cvl/).
  • Sometimes moving among the various flavors of unix is as simple as typing make. For developers, it's not a question of "why", but of "why not?". If a sizable market is suddenly opened up with relatively little code modification (compared to porting to NT) then it's good business sense.
  • I don't really know what sort of terminal emulation/command-line thingie (vt100.App ?) OS-X is going to ship with. If its not available, the 99.999% of OS-X programs are going to use a NeXTStep-like, window based eventing model; which would be VERY hard to port to a NOT Next-like environment. The other way is true also. HOWEVER, I suspect that text programs will be accessible, the implication here is that Linux/BSD/etc programs (character based + daemons) should compile relatively easy. But do Mac Guys write this sort of program ?? Not in my experience. It really seems like the porting flow would be from Un*x to OS-X, not the other way around. Unless of course, someone ports Display PDF/Aqua/etc to Un*x ;)

    Just my $0.02

    -- Rich
  • You had refined your trolling so far it was indistingiushable from real posts. But you've apparently lost it in the past few days.

    For instance, why compare iMac to Sun? SCO, BSD AND Linux all run on Intel. You can get an Intel box for the same price as an iMac and we all know the OS is free....

    Probably the "cheapest and most available system ever to come with a UNIX preloaded" so far is the DotStation from Intel (IBM?) that comes with Linux. I doubt iMac with OS X (will OS X run on an iMac) can beat it.
    --
    Give us our karma back! Punish Karma Whores through meta-mod!

  • Huh? (Score:1)

    by Eidolon ( 29916 )
    Since when does Unix have lower hardware and software costs than Mac OS?

    Free operating systems != Unix. When you say Unix, I start thinking of Solaris, AT&T, SCO, Irix, and so on. Hardware and software costs are much higher in that world. If you mean that free Unix and Unix-like operating systems have lower hardware and software costs than MacOS, then that has pretty much always been true and pretty much always will be. No commercial enterprise can hope to compete with free software for dollar value.

    Undoubtedly, there will be some push in both directions, development-wise. Many current OS X developers are companies that built NeXTStep applications or have Mac/Unix products, like Tenon. Mac OS X is already a respectable server platform precisely because it runs unadulterated Apache, among other things. For server applications, the OS X's BSD heritage is a clear selling point, and OS X is already a pretty good BSD flavor.

    For the near future, end-user applications will primarily run in the classic Mac OS compatibility environment, until more are converted to use CarbonLib (which is happening already). Most of the work being done in the better Cocoa API is by NeXTStep developers; mainstream Mac developers will probably not move on to Cocoa until they've successfully Carbonized their current applications.

    It's going to be a bumpy ride, but hopefully the end result will be worth it. Mac people have been waiting for a real OS that would handle their beloved GUI for years. With Mac OS X, it could finally come to fruition.

  • Re:Haha! (Score:4)

    by spazimodo ( 97579 ) on Thursday July 27, 2000 @09:07AM (#900239)
    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.
  • Look at it from an industry standpoint: If you a head of a corporation than ran a mixed environment (mixed being basically all the major platforms), would you want to purchase a program that can only run on some of the machines, or one that is available for all of the machines?

    Portability helps break down the software barrier. Face it: Most of the cost of machines is not hardware, its software. If developers could write programs that are easily portable (as in the case with Unix and OS X), then software cost eventually would drop (you would be doing less programming for more platforms).

    I know not all of this is possible, but it would be nice for corporations to be able to spend more on their employees instead of the software we need.


    MunITioN
  • No. Apple has a lot more than 3% of the market. They have 3% of the business market. As a whole, they have nearly 10%. Apple sold, last I heard, over 1 million PCs world wide last year. IF what you say is true, than the rest of the world bought 33.3 million PCs? I don't think so
  • I can't see why a company wouldn't want to port their product to an untapped market. The cost of MacOS is under $100, free with a Mac, which can cost much less than a UNIX box.

    If the major stumbling block is reconnecting the GUI, I for one would prefer the excessively-candied Aqua over X anyday. (Something about X's aesthetics just bothers me... =)

    MacOS X definitely represents an opportunity for UNIX vendors to gain access to an even larger base of users. And this could work both ways, with programs developed for the Mac being ported to UNIX platforms.

    At Siggraph, there have already been some statements [zdnet.com] (albeit lukewarm) about porting high-end graphics applications to OS X.

  • If one uses UFS (instead of HFS+) and installs one of the many available (or soon to be available) X11 servers, he/she will wind up with a full-blown kick your ass Unix. So the port won't be any more difficult than any other port.

    There's always an idiosyncratic difference here or there betweeen (Li/U)n(i/u)xes, but thats it.

    As to the question of why? Many many mac power users are quite versed with Unix and use a mac in addition to Unix because in their opinion all of the available Unix desktop environments suck.

    My opinion is as follows: CDE sucks, Gnome sucks at the moment, KDE sucks at the moment, OpenWindows Desktop sucks slightly less that the rest. Hopefully Gnome and KDE will improve, but that is a different discussion.
  • Actually, you're losing your touch. While Linux might be cheapest of them all, among commercial unicies OSX will be the cheapest. SCO costs an arm and a leg, along with Solaris. Most available referred to where it's being sold and market attention. The Mac has the combination of installed base, cost, and market attention that makes it perfect for posts.
  • Comment removed based on user account deletion

  • It is certainly well and good that the "plumbing down below the GUI" looks like BSD, as that represents a well-understood and well-regarded set of "plumbing." That means that you get easy ports of "server side" stuff like Apache, PostgreSQL, Perl, Python, and such.

    But with Apple having had some difficulty deciding what their GUI strategy would become, it's going to be a bit problematic to just plain choose a GUI. Do you go with:

    • Yellow Box?

      Oops. No longer available.

    • OpenSTEP?

      Oops. No longer available.

    • Aqua?
    • Quartz?
    • Carbon?
    • Cocoa?

    The really critical thing about all of these options are that none of them, save, perhaps for OpenSTEP, via GNUstep [gnustep.org], has any ability to run on any of the existing Unix-like systems.

    In effect, in order to use existing Unix apps in GUIed manner on MacOS-X, you need to create a GUI from scratch and layer that on top somehow.

    That may be nicely supportive of "web-oriented" applications; I'm sure WebObjects will work nicely on OS-X, as will the sysadmin tool WebMin, [webmin.com] and so long as you've got a good web browser, that can provide a way of doing a bunch of useful things.

    But that does not provide you with a port of the latest Sid Meier game, nor does it provide a way of running the latest SAP GUI. [sap.com]

  • Under the CLI side, there's the GNU stuff; Emacs, bison, flex, gcc, patch, etc. Most of those should port trivially, if Apple hasn't already provided them with all the Darwin stuff/hype.

    So that should be an almost perfect situation, with very little source mod and no GUI...

    I might have heard a rumor that Apple had created a development harness/framework/GUI around those tools, in which case people would love to port this out of Apple, if that could be done trivially. Even if it wasn't trivial!

    Then there's the other stuff; SSHes, vi's,Apache, SOCKs stuff, that should also be fairly trivial to port since most of them exist in the BSD universe already and are all CLI anyway, again, if Apple hasn't already had them ported for their own use!

    Graphical stuff? What, XEyes? XClock? XEarth? Bah. No comment.

    Mozilla, Quake3Arena, etc should not be a problem.

    What needs to be worried about?

    Bye!
  • Ummmm, I could be wrong on this, but isn't OS(Ten) supposed to run on G4's? Last I checked, the iMac didn't really have the brawn to run OSX.

    Also, who mentioned anything about Sun hardware? Seems the article made statements about Linux and *BSD, not Solaris for SParc.

    -------------
  • Also, Apple is known for designing solid and well performing hardware.

    To the best of my knowledge, a powerPC based server with Apple's knowledge of scsi and firwire should perform as well as, or better than, a comparable intel based system.

    Why port to Intel/WinNT when you can more easilly port to OSX and get better performance to boot?

  • Re:Command Line in OSX (Score:5)

    by Junks Jerzey ( 54586 ) on Thursday July 27, 2000 @09:11AM (#900250)
    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.
  • OT: You can do http://sourceforge.net/projects/DBMix instead of the number, which makes it an easier to read URL.

  • Problems... (Score:3)

    by DranoK ( 18790 ) on Thursday July 27, 2000 @09:12AM (#900252)
    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.

    The earlier /. article suggested (or at least the comments did) that if M$ released IE for OSX that IE could be ported to X. Not quite.

    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.
  • It's important not to underestimate the number of people who are equally appreciative of and comfortable with Mac OS and Unix. Why? Lots of us were first exposed to Macs and Unix simultaneously in the mid-80's, at university.

    There are lot of combination Mac/Unix fans, and OS X should be warmly welcomed by us.

  • Re:Command Line in OSX (Score:3)

    by bonespsk ( 139402 ) on Thursday July 27, 2000 @09:13AM (#900254)
    There is a command line interface currently included with OS X DP4. It's called Terminal.app.

    Here's an example [apple.com] showing tar and gzip in use.

  • If you are getting a little utility (or a huge program) running because you want to use it on an OS X box, then you should port exactly as much UI as you feel is good for you.

    If, on the other hand, you want people to actually use your product, then you should stick to the user interface guidelines that Apple publishes. If you don't, nobody will be angry, but they will simply avoid your software. It's how things work in the Mac world; programs with interfaces that are even slightly weird get shunned.

    I miss being a Mac user. :(

    --josh

  • Why compare the mass-produced imac to an expensive proprietary risc box from a Unix vendor?

    A more realistic comparison would be:

    ~$800 imac

    ~$400 comparable Linux-capable intel box

    Draw your own conclusions!

  • Numerous X11 server ports are available. Last I checked, every (I use the loose sense of the word) UNIX gui is X/Motif based.

    So GUI is no problem.
  • Actually OS X will run on the iMac with ease. I was simply comparing prices of UNIX workstations. The iMac is cheaper than most hardware you'd want to run *NIX on, and a lot better looking to boot.

    The article said UNIX. The Slashdot story said UNIX. UNIX means Solaris and SCO, not *BSD and Linux.

  • I think you are looking at the wrong end of the scale

    High end Sun: a few million dollars. (3 If I remember right, but when you get into these systems discounts are the norm, not to mention all the other hardware you would typically buy with it)

    High end Mac: $15,000, and I don't think they have had a machine that expensive in a few years.

    hmmm... I don't know what SGI sells sytesm for. IBM considers their RS6000 a low end unix machines. God knows what Dec is doing. (I refuse to use the C word on them or pay attention to the C company)

    Of course linux and *BSD generally runs on cheap x86 machines, as does SCO. The biggest unix market by far, but not the only one.

  • um.... so that would be why i'm running linux on a G3 tower right? and why i've still got a 512k mac in the garage? and why i work part time at a mac dealership? because i'm clueless about macs :) my comment was in response to server admin's needs for programs, which are prolly command line to begin with. lemme restate my question and see if i can be clearer: 1. X is already ported, and will run under whatever they call the gui when it's released 2. gcc is already ported. 3. if we just port the various toolkits that the current guis are written in, why would we need to redo the interface?

  • Developer? (Score:4)

    by Accipiter ( 8228 ) on Thursday July 27, 2000 @09:19AM (#900261)
    The hardest part, according to Robert Palmer, will be writing the GUI (graphical user interface) front end to make administration easy.

    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?

  • Aqua -- not much more than a term for the watery, bubbly appearance of the developer-stage Mac OS X interface skin.

    Quartz -- a PDF-based system-level imaging model. This is the Mac OS X component corresponding most closely to X11.

    Carbon -- a forwards-compatibility library to ease the pain of classic Mac OS developers in porting existing Mac OS applications to Mac OS X.

    Cocoa -- the "native" API for Mac OS X development.

    "Choosing a GUI" is not going to be as hard as you seem to think. Carbon and Cocoa are the APIs, and Quartz provides display services to the entire system. They are separate entities.
  • I think a more interesting question is whether some of the mac developers as they update their software will find that it is relatively easy to port to unix. Maybe it's just wishful thinking but it's an interesting thought. The mac world's strengths (apps and user interface) and unix world's strengths (reliability & networking) are somewhat complementary so it is a nice thing to hope for at least.

    This also might have the highly desirable side effect of forcing some folks writing unix software take Apple's lead on user interface issues. Since Apple is generally considered one of the best at user interfaces, perhaps some of it will rub off. :-)

  • I thought I saw a reference earlier this week to a company that is bringing out an X server... so in theory one could just use X on OS X (man is that gonna get confusing, worse than the client/server naming in X :)).

    Personally I can't wait. I love working on my Mac but you can't beat Unix for flexibility. Now we get both integrated.

    My main concern though is getting PPC compiled binaries. For example, CMU Common Lisp does not have a PPC version. Maybe this is just because it is a compiler issue - but do Oracle have plans to release Oracle 8 i for the PPC platform ?

    Winton
  • "Actually, you're losing your touch."

    Claim with no attached meaning, let alone evidence.

    "While Linux might be cheapest of them all, among commercial unicies OSX will be the cheapest."

    Possibly true (is pricing for OSX available yet?) but utterly irrelevant. Why limit discussion to "commercial unicies" [sic]?

    "SCO costs an arm and a leg, along with Solaris."

    Non-sequitur.

    "Most available referred to where it's being sold and market attention."

    This appears to be English but is not well-formed.

    "The Mac has the combination of installed base, cost, and market attention that makes it perfect for posts."

    "The Mac" no longer exists. There is MacOS and there is OS X. OS X has zero installed base. Cost has yet to be determined. "Market attention" and $.75 will buy you a cup of coffee.
    --
    Give us our karma back! Punish Karma Whores through meta-mod!
  • >How hard would it be to set up an option in the
    >installer for "command line only"?

    Well, it's not an option in the installer, but in the developer preview versions of OS X, you can kill -9 all of the Aqua gooiness and be left with a big honkin fullscreen tcsh shell.

    I don't see how they could take that ability away in the final version unless they deny their customers the root login, keeping it for service techs only or something. From what I can tell by using DP4, it does NOT appear that that is in the cards. You have to su (well, a graphical equivelent) from user to root whenever you want to change important system settings. They've put a good deal of work into making su functionality as transparant as possible. Denyng root NOW would mean throwing away a good deal of work already done.

    Plus, I imagine that if they *DID* deny the buyer the root login:

    1) They would be pubicly roasted alive by nearly everyone... a PR nightmare to say the least.

    and

    2) It would be cracked soon enough anyway, so there'd really be no point

    So it's not bloody likely that Apple would deny OS X buyers root on their own boxen. So I say just modify rc.d to your hearts content.

    john
    Resistance is NOT futile!!!

    Haiku:
    I am not a drone.
    Remove the collective if

  • Cool, thanks, I wish I was more up to date on Mac hardware/software like I used to be. Actually, I'm an advocate of the "multiple virtual terminals in a graphical interface" way of doing things, in my original post I was just trying to say that having a command line only option would please the OTHER people out there who insist on not having the Aqua/X/whatever graphical interface.
    -colin
  • If you're porting UNIX tools to the mac though, expecially OS X as it is right now, you are already pandering to power users.

    I think you may also may be misjudging mac users. I don't think it is an issue of interfaces being pretty, as much as being good. You give an example of mkiso and cdrecord as applications which don't have any front end. I'm assuming you have heard of xcdroast? It's been around for quite a while. It may not be quite as pretty as many mac apps, but it allows a level of power that the oversimplified Mac GUIs currently tend to lack.

  • hmmm... interesting math =) Any reason for deducting 2 million from the low end and 4 million from the high end of the range...?

    Anyways, I highly doubt that upper figure. Especially considering this recent report [maccentral.com] by IDC at MacCentral about Linux overtaking the server market. ...current numbers that show Windows having 87 percent share of a 98.5 million shipment market...and Linux paid copies having just under four percent.

    Even if you were to say every Windows user in the "shipment market" had Linux on their machine, you still wouldn't hit that high number. And the low number indicates a 50% market share, also unlikely.

  • I really don't think the stability of unices is thanks to the apps. Unices are built so that an app can't screw up the system, but I don't think I can say I've noticed unix apps are more stable or less stable than windows/mac apps.
  • Apple has had some difficulty in their GUI strategy, but I don't think that you have your terms correct or I am grossly misunderstanding what you are trying to say.

    Aqua, Quartz, Carbon and Cocoa all stand on different layers in the overall scheme of Mac OS X.

    Carbon and Cocoa(AKA YellowBox) are APIs, and your decision to use those APIs in programming probably doesn't have a lot to do with what GUI you have decided on.

    Quartz is not a GUI. It is an imaging/graphics model for displaying things on th screen.

    Aqua is the GUI, and the you have really no choice except to use it when you are building your apps. However, since Aqua sits on top of everything else, you can theoretically swap it out with another type of GUI, at least when you are talking about widgets and their functionality.

    The problem, as I understand it, is with X apps, because they require a certain level of interaction with hardware(because of X), that makes it difficult to implement because Apple has Quartz. That, however, is all being worked on and you should be able to port your X apps to OS X with some minor difficulties.

    That being said, I don't think many people are more interested in the "server side" stuff and any admin tools, etc., will be new projects considering what is involved.

    remy


    http://www.mklinux.org
    http://www.dartmouth.edu

  • MacOS X should ship for $100, and will run on at least all Macs with a G3 or G4 chip. There was 3.7 millions iMacs sold in the past two years. Probably quite a bit of Powerbook and PowerMac G3/G4.
    The dual G4/450 box for $2500 is pretty sweet too.

    Now if you refer to the two or three discussions about Mac developpement in the past on /. you will see that Mac developpers make plenty of cash. It has a large userbase that is loyal and pay for its softwares.

    So, why wouldn't unix developpers tap into that market?

    The UI part wouldn't even be that bad, for X-windows apps, you have a couple of X-windows clients/servers for MacOS (8/8 or X).

    Last but not least, I wouldn't be surprised if some unix fox switched to MacOS X. After all, it's unix, the core (Mach kernel, BSD libs) is open source, the hardware is robust (if somewhat proprietary... but then the components are probably more standards than the ones on a SUN box), the GUI niiiice, and it should be plug & play. And access to all the Mac software (including games), if I'm not mistaken there might be more non-server/dev apps for the MacOS than most flavors of unix.

    Oh yeah, and no need to dual boot to play games :)

    Just some thoughts.

    Janus
  • OSX has always been meant to run on either a g3 OR a g4. This goes WAY back. That plan has been in place for a while, and is the reason why OS9 doesn't run on non-g3's and I believe OS 8.6 was the cuttoff on powerpc's.
  • iMac w/ G3-350 runs DP4 of OSX quite well. Even beige G3s can run OSX. 7100 with a G3 upgrade doesn't though... probably no NuBus support, anyone tried it on a G3 upped 603 or 604 PCI mac?

    Granted it is faster on a G4, but so is everything else.

  • Are we talking about porting BSD tools to OS X so they work the same way?

    Or are we talking about rewriting BSD tools so they have the friendly, consistent graphical interface that people expect from a Mac?

    IMHO, they're completely different issues. Generally free software developers are willing and eager to make their code more widely useable through portability, but not too keen on spending their own effort to dumb their stuff down instead of spending it on adding functionality.

    ---
    Despite rumors to the contrary, I am not a turnip.
  • Mac OSX boxes won't be the cheapest or the priciest, but they will grant excellent value. We run Sun backend and Mac frontend in my shop. Apple hardware is generally excellent, as good as Sun is in terms of failure rate. Subtract harddrives and none of our Macs or Suns has ever had a significant hardware failure.

    You can always drum up a comparison that will prove any cheaper/not cheaper beef, but a Un*x OS running on G4s with a potential wealth of open source and commercial software that I'm used to using sounds great to me. We will still run the OS that is right for the job, we have numerous linux boxes and NT boxes around. We were one of the first to slap linux on the Apple Network Server when the AIX two-user license proved to be a hinderance.

    So from the mac/unix user perspective, I have been waiting 5 years for this kind of Mac.

    Will it replace my Suns? Not soon, unless I can get a firewire-ready Hardware RAID and hot-swap power.

    Now in terms of software, if a Mac::Aqua ever surfaces in CPAN, what more could I ask for?

    I have had some pretty big roadblocks compiling GNU stuff on my OSX laptop so far though. A lightweight like me would need more by way of HOWTOs or configure scripts to get by. (Sometimes adding "darwin" to the configure scripts where you see "rhapsody" is good enough).

  • it's fun, but... (Score:4)

    by Anonymous Coward on Thursday July 27, 2000 @09:46AM (#900313)
    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. :)
  • We finally have the opportunity here to redesign the actual configuration interface for UNIX programs. If we recoded the apps to use XML, we could have a consistent interface. Heck, we could use PyGNOME and use the same program to administrate and configure all of the apps.

    I'd really like to see something like this done just for the sake of showing up all of those windoze zombies. You want a consistent, graphical interface without the idiotic registry? Use Unix!
    You prefer command line? Keep using UNIX! Used to MacOS? You're using UNIX!

    World domination... Cool...
  • You're really confusing a bunch of issues, hopefully not maliciously. Cocoa is jsut YellowBox renamed, to emphasize that you're supposed to code under it in Java, and to make it sound less like a container of piss. OpenStep was what cocoa/yellowbox was before Apple bought it from Next. Quartz isn't a gui-- it's a rendering engine, replacing Display PostScript. Aqua is just a theme.

    Apple is guilty of not getting this all out the door sooner, but that's about all. That, and killing cross-platform YellowBox/OpenStep frameworks.
  • Ah, but Mac OS X is essentially going away, to be replaced most likely by a set of extensions to Mac OS X (same way AppleShare IP sits on top of OS 9). So there's really only one system to port to.

    I for one as a part-time Mac developer am very excited. (I'm actually posting this from DP4 with OmniWeb, and it's been remarkably stable, even when chewing on rc5 in the background.) I would love the opportunity to serve both communities by a) porting useful Unix apps to OS X and b) bringing some of the ease-of-use of the Mac intoerface to a Unix app. I think it's going to benefit both communities tremendously, assuming some Unix users can get over their anti-Mac bias and some of the more die-hard Macophiles can accept that there is more to life than the Mac OS. (Hey, it could happen!)

  • OSX=$99. Puts it all into context, doesn't it?

    SCO does cost an arm and a leg. So does Solaris. OSX is cheaper than both of those

    Hmm, I was able to get a CD with SCO on it for $15 and I was also able to get a CD with Solaris for Intel for $20. My cost for SCO + Solaris is $35. OSX is $99 which I can't get yet. So much for your cost compairison... Wait you said that it costs an arm and a leg and I still have both arms and both legs so your estimate must be way off. Of course I was able to get Solaris for non commercial use and you might be comparing to the full price.
    Molog

    So Linus, what are we doing tonight?

  • And with GNUStep you can keep your software free! (Score:4)

    by Carl ( 12719 ) on Thursday July 27, 2000 @09:49AM (#900323) Homepage
    If you decide to port to MacOS X please try out GNUStep [gnustep.org]. That way you can keep your software free and run on MacOS X when it finally ships.

    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.

  • actually if you max out everything at the apple store it comes to a grand total of 17475 (only 419 a month for 72 months, act now, supplies are limited!) the specs: Dual 500mhz G4, 1.5GB ram, 216GB HD (3X 72 GB Ultra 160SCSI)Apple Cinema display (22" Flat Panel), Zip Drive, DVD-RAM drive, Ultra SCSI PCI card, 3x ATI RAGE 128 cards, 3 year apple service agreement. mmmmmmmm computer

  • That isn't true at all. Let's be at least some what reasonable. A $400 Intel box:

    1) Has a $300 or $400 Compuserve Rebate
    2) Has a Celeron (read: shitty CPU)
    3) Is most likely not as fast as a G3 iMac with 64 or 128 RAM, and a 6-10 gig HD, with a ATI based video accelerator.
    4) The iMac has a monitor. Your $400 Intel box (after the Compuserve raping) doesnt have a monitor.

  • > not too keen on spending their own effort to dumb their stuff down

    First of all, I think we should throw out erroneous assumption that lurks behind this statement, that a consistant, logical, easy to use interface (like Mac OS) constitutes "dumbing down." Apple used to say that "simplicity is the ultimate sophistication" with great justification. There are many benefits to be had from clicking a button rather than entering several lines of code, just as there are benefits to entering a single text command rather than renaming each of 20 files individually.

    Civilization advances by the number of things we can do without thinking about them. In fact, that's why we have computers in the first place...

  • The beauty of GNU and the various "open" licenses is that if you have an app that is good enough and meets a need, you really just need to get the thing to work on MacOS X, then somebody who likes it from the Mac camp will probably build a more Mac-ish front end for it, and everybody will be happy. (Especially ESR, who seems to love nothing more than open source success stories; anything to sell a few more copies of "Cathedral..." to business managers and marketroids.)

  • Re:What is there to port? (Score:3)

    by Phroggy ( 441 ) <slashdot3@ p h roggy.com> on Thursday July 27, 2000 @10:00AM (#900339) Homepage
    Apple has already ported most of the CLI stuff. Basically, anything that comes with a default install of (I think) FreeBSD 3.2 has already been ported, and other stuff will follow. There have been a couple different ports of SSH floating around for about a year now. I believe Mozilla has been ported - they just Carbonized the Mac OS port. As for Q3A, John Carmack loves Mac OS X; this and all future id games will be ported.

    --

  • 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
  • Tenon Intersystems [tenon.com] has already announced X (as in X11R6.4 [tenon.com]) for X (as in Mac OS X [apple.com]).

    Therefore, for simple ports, it should be a no-brainer.

    Carbon or Cocoa ports will demand a wee bit more work, depending on the app.
  • OS X Server is dead. Apple is not going to have a dual OS strategy like Microsoft. Mac OS X will be the only OS. It's just as much a Unix as OS X Server is, Apple just hides it from the typical user better. All the Unix goodness is there if you want it.

    --
  • Porting of most UNIX applications to Mac OS X won't happen unless Mac OS X gets a free X11 server or X11 compatibility library. A commercial X11 implementation won't provide sufficient incentive because it means that people have to buy and install another, separate product just in order to use free software.

    The simplest way of getting X11 on Mac OS X (or Windows, for that matter) may be to port the UNIX VNC server. It implements an X11 server and frame buffer completely in software.

    If Apple is smart and wants to go for this market, they should start including X11 compatibility in their base system.

  • My main concern though is getting PPC compiled binaries. For example, CMU Common Lisp does not have a PPC version. Maybe this is just because it is a compiler issue - but do Oracle have plans to release Oracle 8 i for the PPC platform ?

    Points to consider:

    A) Larry Ellison (CEO of Oracle) is on Apple's board of directors and is one of Steve Jobs' closest friends

    B) Ellison hates Gates

    C) Porting Oracle to Mac OS X in no way hurts Oracle

    D) Porting Oracle to Mac OS X does help Apple

    E) Anything that helps Apple hurts Microsoft

    --

  • GUI's rely on pattern recognition, while CLI's rely on memory (i.e., click on "find" instead of typing a grep command).

    The disadvantages of each tend to be overstated during Holy Wars, but the jist of it boils down to this:

    GUI's have a tendency to limit options for the sake of simplicity and eat more processor cycles. CLI's create less load on your system and don't have to worry about being pretty, but if you forget the exact -Option that you need for a command, productivity stops while you read MAN pages and O'Reilly books.

    IMHO, most GUI's absolutely suck. MacOS has always been the GIU that sucks the least, in that it has all the simplicity for the luser that you get from a shell-built option screen, but the rewards of spending time learning how deep the rabbit hole goes are actually way beyond what most non-mac geeks tend to assume.

    I will grant that if you are a Linux or Windows guru, the Macintosh Way looks incredibly unappealing from the outside, but if you were to spend the kind of hours learning the Mac's more obscure abilities that you spent learning sed and awk (or M$-SQL, to use a Windows example), you would probably dig it.

    Amiga and Be zealots are free to ignore every word I said here. There's just no reasoning with you people. (I'm just kidding. Please put the gun down and I will let you tell me all about CPU efficiency and how sadly misguided I am.)

  • You didn't take the MacOSochists into account...
    the ones who hack the mac...
    I've successfully installed and run 9.0.1 on a 7100 (PPC 601 80; SCSI, ADB, 2x CD; 1 MB vram (after upgrade, IIRC); 1 NuBus filled with a second monitor) with 128 MB ram. Not zippy, but doable. I know someone who installed 9.0 on a stock (with 56 MB total ram) 7100 as well.

    Remember: Supported != Exclusive to.
  • The bad news: I don't think OS X DP4 will install on any NuBus or PCI 603 or 604 based Macs. The good news: Darwin runs on some of these platforms (604/PCI, maybe more), and as Apple incorporates these changes into Mac OS X, it will install on these machines. Furthermore, someone could probably hack out support for NuBus machines for Darwin as well, thereby making it possible to run Mac OS X on these machines.

    It is now and has been for a while the main point of Darwin is hardware support. What most people realize is that this hardware support doesn't just mean support for perephrials but systems themselves.

    Want Mac OS X on your 110 MHz 601 NuBus box? Lift the NuBus support information from MkLinux sources and adapt them to Darwin. While this isn't a non-trivial cut and paste job, and the version of Mach which MkLinux uses is different than that in Darwin/OS X, that similarity makes it not only quite possible, but a project which would probably not take all that long.

    Apple may not have made up pretty spec sheets about it's hardware for you, but it put all the documentation you need in MkLinux, so quit whining about it not being an "open platform" when it's been in your lap the whole time.

  • Re:Command Line in OSX (Score:3)

    by jetson123 ( 13128 ) on Thursday July 27, 2000 @10:22AM (#900363)
    A text mode console is useless for desktop use, but that's only one of many applications of computers. Text mode consoles are very useful for server farms and other applications. The problem with Aqua, for that matter, isn't its appearance, it's its lack of remotability.

    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.

  • There is no reason not to support all the possible customers you can if the cost to do so is low. As the number of users using unix os's at the moment is small (compared to Windoze), companies which do produce applications for the different unixen will most probably fall into two groups: those who also produce a version for NT/2000 (because there are just too many of them to ignore) and those who only produce unix versions.

    To take the latter case first, the number of potential Mac OS X instances out there is close to the same number as of all other unixen combined. Those who produce only unix versions of software have the potential to tap into (say) twice as many potential customers, and the port will be much easier than porting to Windoze because they only have to deal with GUI issues (assuming there are any - e.g. porting cli stuff should be trivial), rather than GUI + Crappy OS + Different OS.

    As for the former case, any company that has gone through the pain of porting to Windoze will likely have taken two routes: the dumb way, i.e. Branched their system entirely so that there is separate development of both versions and ne'er the twain shall meet; a smarter way, abstracted the GUI as much as possible from the logic. If they went the dumb way, the port will be harder and more expensive, so they may not see as significant an advantage - though it also means that they are doomed to waste lots of money as fashions in OS's change. The smarter way however, means that they can reap the benefit from their previous pain: the port will be much easier, and given that they seem to find some profit in their other unixen, the effort will be justified. Again; the GUI is the only real stumbling block: anything without a complicated GUI would be trivial, and OS X would just become another flavor of unix, offering a large number of potential customers.


    The other potenial for crossover is for Mac Developers who have remained largely in that market to start developing (say) Linux versions of their products because they have already made the core logic of their products unix-ish. Such companies would essentially be just like the unix-only product developers; they get the advantage of a much larger market for their wares with a much reduced cost of porting.


    In general, how couldn't there be an advantage?

  • Why not call it... (Score:3)

    by cvd6262 ( 180823 ) on Thursday July 27, 2000 @10:26AM (#900370)
    ....or at least pronounce it "OSIX"? It's true that it's more a *NIX than anything else, so why not start refecting that in the name. I say we steal this idea from Micro$oft and make other companies change their vocabulary (it's a DIRECTORY, not a FOLDER).

    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.

  • This is great news, I'm hooked. I really like the Apple hardware, but I refrained from buying Apple until now, because I really need remote login and a Unix shell, and I refuse to work on anything resembling the crude old thing they used to call an operating system.

    Now I will walk in beauty again.


    © Copyright 2000 Kristian Köhntopp
  • did you ever wonder why apple went to dual processor instead of just increasing the speed of the g4. mainly because they cant. and they have to increase with the rapid speed jumps of intel.

    That is completely wrong. Apple has no control over G4 production. That is Motorolla and IBM. They have to agree in their alliance on a path toward faster chips. Currently, they are in a little tiff.

    The second thing, is that Apple doubled up on the chips for marketing reasons. A RISC based G4 and a CISC based Pentium can not be compared by Mhz, but everyone here knows that. Problem is, the people out there (Joe Consumer) don't know that. Steve Jobs knows the G4 500 gives a Pentium 800 Mhz a run for the money, and he also realizes that the speed gap is getting tight, and that Mhz gap is huge. So mainly for marketing reasons he doubled up.

    There are Multi Proc. libs in OS 9. The dual processors do speed up threaded apps and the OS. It is not a 2x speed increase, but it is significant enough. There are quite a few apps optimized for MP machines. Photoshop being a one of the big ones. Mac OS X (coming soon) will fully support SMP (Symetric Multi. Proc I believe). So you won't have to worry about it.

    That's my rant.

  • Re:UNIX guys dont need GUIs (Score:5)

    by Golias ( 176380 ) on Thursday July 27, 2000 @10:43AM (#900385)
    "...but Apple is doing their best to make sure that the end user will NEVER have to see the BSD side of things, unless he wants to.

    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.

  • Assuming that only 5 million to 10 million of the 30 million or so Mac users. (Yes there are that many. A conservative number.) Then a commercial Unix vendor will suddenly have a huge market to exploit. That will be much less effort to port then a Unix -> windows port. There will be commercial and free ports of X which will take the work out of doing the GUI. Mac OS X is also totally POSIX compliant . A added bonus. For free programmers, and commercial vendors alike this will provide a exciting oppurtunity to expand there user bases, and give there users another option.
    Cheers,
    WFE
    ===========
  • 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.

    OK, so I bought my first Mac in 1984 and my second Mac in 2000. In between, I've mostly been a Unix and Linux user, using X. From the screenshots and reviews I've seen so far of Aqua, I've seen both good points and bad. The worst point I've seen, by far, is the apparent inability to work on multiple virtual screens. My Linux desktop has been three screens wide and three screens tall forever; under gnome, I now have a fairly minimal and unobtrusive tool bar, too. The most important part of my user experience, however, is the fact that I can have 3 different full-screen Xterms, a fully maximized XEmacs session, a Matlab session, 3 full-screen browswer windows and an "extra" blank screen all going at the same time. I'm never more than 4 keystrokes away from anything, and I never have to use the mouse if I don't want to. It's glorious. No overlapping windows, no fonts smaller than 18 points, the focus is always where I want it, and I always know where I am.

    But, alas, apparently not currently possible with Aqua, where they seem to believe that people really want to have only one virtual screen on their one physical screen, and really want to keep track of a half-dozen or so "open" (but docked) applications or documents. Feh. To be fair, I only discovered this One True Way since the release of fvwm, and I've never seen anybody use this on a non-unixy platform. But what galls me is that Apple really did have something like this working back in 1986 (I believe) with Andy Hertzfield's "Switcher" when you could "virtualize" your Mac 512K (or above) into 4 (or more) 128K Macs with their own screens. Most people thought this was all about running multiple programs, but it was *really* about eliminating screen clutter. But then the idea got sucked up into the vortex of history, and what got spat out in the end is the lame cooperative multi-tasking set-up that MacOS has been stuck with ever since.

    I'd like to like Aqua, but I really must have my virtual screens. Okay?

  • I used to be a mac developer. I worked on several high profile mac projects, and more than my share of commercial flops. During the iMac boom, developers were being snatched up right and left to create the next wave of software. This boom brought my some very nice work. Yet it is still in vain....Even with the iMac boom and Apple profitability developers are being mistreated by Apple. This is probably the biggest source of frustration for me. To get on the professional mailing list for Apple costs something around USD$400. Their developer tech support (DTS) has been going downhill since 1992. I won't write muchless port to Mac OS X, I won't even write for it. I grew up on Macs, learned how to program on macs, but I'm cutting the line. Most Mac software writers I know struggle, they barely make ends meat. Now that I write Windows software, I seen the life of luxury! There is something to be said about massive stock options. The Mac market is so small, hardly any software companies out there are big enough to offer stock, much less stock that is worth something.

    The future? Apple's future is still as grey as ever in my opinion. They still don't have a clearly defined market (the iCube just illustrates this). The past 4 years have just seen them try one thing and back off. Mac OS X may survive, but does anyone really care? It's not as open as linux, it still costs more than an eMachines running redhat. I don't think Apple will ever die, but I seriously doubt they'll truly thrive. Free software won't change that either. The average Home Joe won't download unix software, compile it, and run on the weekend. They don't know how, and they certainly don't care.
  • familiar unix services like telnet, sendmail (or postfix, of course), ftp and nfs are installed

    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.
  • 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.

    The kernel is not proprietary. In fact, the complete, functional core OS, called Darwin, is open source:

    http://publicsource.apple.com [apple.com]

    From what I've read on the Darwin developers' list, there's already an X server running on it, and the Intel port is booting.

  • There was a virtal screen app for OpenStep known as "VirtSpace" ... There is nothing that indicates that it would not be possible to port or recreate it for OSX. It's just not going to ship with OS-X.

    Burris
  • I'm not a sysadmin nor do I have extensive experience with Unix boxen. Somebody out there surely has shopped for and uses Unix workstations. Therefore, I ask you to confirm or not confirm my impression that many Unix boxes are far more expensive than a Mac. What are the ballpark prices for the various workstations below?

    A Sun Solaris Workstation
    An HP PA-Risc (did I get that right?) Workstation
    An IBM AIX Workstation
    A Compaq Tru-64 Alpha Workstation
    An SGI Irix Workstation
    A SCO Workstation
    A BSD Workstation
    A Linux Workstation
    An OS X Workstation

    I'm guessing the OS X Workstation will be priced on the low end, obviously not as low as a Celeron/Linux box but not as high as a Sparcstation/Solaris box either.

    Also, I'm wondering, how far is each platform entrenched in the real world? Are there more businesses, universities, laboratories, etc. using Intel/SCO boxes than Sun or HP boxes? What I'm getting at is that there are cheap Intel boxes out there but is anybody using them to a great extent or are they typically shelling out the cash for Sun/HP/IBM/Compaq boxes?

    I think we may find that the statement of Apple hardware and software being more expensive than what is expected in the Unix world is greatly exaggerated. In fact, I bet an Apple workstation will be a pretty good deal.
  • It's an old falacy you guys are spouting here.

    "My puppy was 5 inches tall last year, and ten inches tall now. I need a bigger doghouse, because it will be almost seven feet tall in three years, and bigger than my house two years later."

  • > Most Linux users are for servers

    Source for this claim, please?

    We know from Netcraft that we have around 5 million servers running Linux (less some portion that represents virtual hosting). Now suppose your claim is wrong? Where does that leave the relative sizes of the userbases?

    I know quite a few people running Linux on their desktops at work, at home, or both. So far as I know, none of them are running it as a server. Perhaps this is a statistical fluke, but since you provide no basis for your claim whatsoever, I'm going to assume that my slice of the world is typical, and that there are more Linuces on the desktop than in the server barn. At least until someone presents some actual facts or solid arguments to the contrary.

    --
  • I dual-boot OSX DP4 at the moment and I have some experience porting over various unix programs.
    How hard is it, do you ask?
    Well, it's DEAD easy. All of your common libraries are there to use (ncurses, for example) and all of the common development tools are there (gcc, autoconf, etc...)
    Many programs will compile and install fine with just a:
    ./configure
    make
    make install

    For the ones that won't, you'll probably just need to do something like:
    ./configure --host=freebsd

    or something similiar to have the script get some sort of handle of what type of system you're running. At the most, I've had to modify the configure.in to tell it where to find things that are in non-standard locations (the Java libraries, for example).

    I'd say 99% of these issues will go away whenever a revision of autoconf comes out that automatically knows something about OSX (Apple changed the uname between OSX Server and DP4, for example).

    I'm very serious when I say that right NOW (in this pre-release version) you WON'T be disappointed when it comes to porting over command-line tools.
  • > How easy is it to port existing Unix apps to MacOSX? The answer is: easy because of the existing BSD API and the x11/Motif/Less-tif libs that have already been ported to the platform in both Open-source and commercial environs.

    Which means that commercial software shops can now see a |market| = |MacOSX| + |Linux| + |Unix|, with very little configuration variance across the whole market. This should tempt more companies into ventures like what Loki is doing with games, and perhaps also tempt more into writing original native applications as well.

    As for non-commercial software, our mindshare just grew in proportion to the same marketshare formula.

    As a side note, I'll mention that there is already similar activity for applications running under X on Windows systems. Freeciv, for example, already runs under Linux, Unix, VMS, and Windows. Now we can add the Mac too, eh? It turns out that the much-despised X is the infrastructure that allows building the world's most portable GUI applications.

    --
  • There was a virtal screen app for OpenStep known as "VirtSpace" ... There is nothing that indicates that it would not be possible to port or recreate it for OSX. It's just not going to ship with OS-X.

    Thanks for the pointer; I hope you're right. :-)

    I'm still a bit worried, though, since the Dock seems to have become such a big deal in MacOS X, that anything that works around that could end up causing problems. (OK, last I heard, you could kill the Dock off, but I didn't hear what you could do, if anything, to replace it or work without it.)

  • Re:Don't port. Write. You'll learn something. (Score:3)

    by MacOSNeedsDeath ( 140242 ) on Thursday July 27, 2000 @12:22PM (#900435)
    I think Dennis Ritchie said (in the Anti-Forward to the Unix-Haters Handbook) something along the lines of: "the systems you admire are not only out to pasture, they are fertilizing it from below."

    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.

  • umm...do you know what BSD stands for?

    That would be the Berkeley Software Distribution.

    As in Berkeley, University California of, hotbed of UNIX research. Originally Unix was invented by Bell Labs, then Berkeley licenced the code for academic use. Originally it was a great deal but as UNIX grew in popularity, AT&T dramatically raised prices for the source code release. In response BSD was re-written so as not to contain any of the original AT&T code. For more information, see the UNIX system administrators guide by Nemeth et. al., page 1. (BTW if you are a UNIX sysadmin, you should have this book.)

    Linux may not be UNIX but BSD is indeed. UNIX does not necessarily mean a System V OS.

  • Objective-C has an (arguably) annoying syntax, limited type checking, no access control and lacks exception handling.

    So, in other words, it is a real programming language! Hahahahahaha! Great! I love it! More, more!

    ps: You can have my FORTRAN compiler when you pry it from between my cold, dead, ummm... 9-track tapes. {grin}

    WWJD -- What Would Jimi Do?

  • Objective-C has an (arguably) annoying syntax, limited type checking, no access control and lacks exception handling.

    It has been a while since I last used the OpenStep API, but IIRC, there were macros NS_DURING, NS_HANDLER, and NS_ENDHANDLER which you could use to bracket code like try { } catch() { }, and exceptions were raised by the raise message to an NSException. It's not as pretty as Java's language-level exception handling, but it's still there. And hey, Python doesn't have access control either. Remember the programmer is in charge, even in OO programming; s/he shouldn't have to directly access private object data normally, but s/he should be able to when the need arises. :-) -Joe

    - Joe

  • 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,

    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
  • 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.

    Sure, that could be done. No problem. But I don't think that would be the best use of nerdpower. To my eye, Linux apps are generally pretty poor in the UI category. Just because there's a menu and buttons, that doesn't mean it's "user friendly". I give TkRat as an example.

    It would be better to think carefully about what you're purpose is and who your audience is and build from there. Gnumeric is a good program, sure, but to compete with MS Excel, you don't have to match feature-for-feature, but make the way the user interfaces with it easier and cleaner, with good, to-the-point help. (needless to say, don't emulate the dancing Mac SE/paperclip).

    The Mac interface is heavily influenced by it's original toaster design: screen space is valuable, don't fill it up with pretty widgets, and only have a single menubar. It caries over to larger screens well, because it's easier for people to get confused when there are multiple menubars on the screen.

    Total rewrite? Well, maybe. But by doing so, perhaps the whole Unix community can benefit by looking at current paradigms and re-thinking how things can be done.

    Of course, this is purely my opinion...

  • how many of the applications and what not do you think will actually take advantage of the dual processors?

    I think very many will.

    im not sure how it works on mac hardware but on intel it has to be designed with dualprocessors in mind.

    Exactly, and the reason that non-SMP software is uncommon on Intel hardware is that most people run fairly primitive operating systems on it, with a legacy going way back to when SMP wasn't popular.

    But among software that uses Mac OS X APIs, processor scalability should be about as common as it is among BeOS apps. (And that's pretty good.) When Mac OS X hits the streets, SMP machines will be fairly common, especially among the developers. If developers have SMP, you can damn well bet they'll write code that uses it.

    Another thing to think about is that as the APIs get higher and higher-level and provide more services, the OS itself (or whatever standard components that people use) will have more opportunities to take advantage of parallelism themselves, even if the app writer doesn't think about it. Joe Schmoe might not think about SMP, but the hacker who wrote the classes that he uses, did.


    ---

  • X11? VNC? Sounds ugly.

    Isn't more Unix GUI development done with a fairly limited number of different toolkits (e.g. qt, gtk, etc). Why not just port the toolkits?


    ---
  • "Will UNIX developers want to port their applications to an operating system that costs more in hardware and OS software both?"

    Come on and get a clue! As RMS is so fond of telling everyone who will listen (or who won't for that matter), free software is not about price! If he was interested in no-cost instead of open source, he would have founded the Freewarez Foundation.

    And if you look at commerical Unix systems, you'll find with only a few exceptions, that they all cost much more than Apple, both for the hardware and the software.

    Who gives a rip what a Macintosh costs? If you're a commercial developer, go out and buy one or lose that market! If you can't afford a single Macintosh to use for porting, maybe it's time to rethink your whole business model from the ground up. I've lived so long with developers telling me I have to upgrade my hardware in order to use their software that I just don't have sympathy for this complaint of theirs.
  • LNAWTBFEUOA: Linux nerds are worse than biochemists for excessive usage of acronyms.

    My yeast-2-hybrid system wasn't working yesterday because I added too much EDTA to my HEPES buffer. This caused a pH overload and resulted in my PIPES ppt'ing. I checked for proteases with PMSF and found to my surprise that I had a HIV virus in my T-cells. Well, batteries never last long anyway. If I could just increase the resolution of my Yeast-2-hybrid screen I could do away with the T-cells all together and use the B-cells. If only they would respond to MHC complexes (type II that is). The network issues here are just toooo cytoskeletal for my CNS dude!!!!!

    Disclaimer: I understand ~1/2 of the acronyms on this thread and now I know how elite I must sound somtimes.

    Can you judge a man by his acronyms?

  • not CP/M (Score:2)

    by hawk ( 1151 )
    One of CP/M's problems when the hard disk rolled around was that it *didn't* have directories.

    CP/M had a four bit numerical user, and only files from the current user setting (no security; you just told it which user to be) and those for user 0 were visible. There was no protection, iirc, to prevent user 7 from overwriting a file with the asame name in user 3.

    By the mid 80's, CP/M-86 was running MS-DOS executabiles and reading MS-DOS disks, but couldn't access MS-DOS directories.

    OTOH, CCP/M (later CDOS, later DR-DOS, etc.) could multitask MS-DOS programs on an 8086. But the lack of directories was a killer . . .

    hawk

Slashdot Top Deals

As long as we're going to reinvent the wheel again, we might as well try making it round this time. - Mike Dennison

Close