Slashdot Mirror
Why Port from UNIX to OS X?
mblase asks: "According to a recent MacCentral article, one of the benefits of Mac OS X's NeXT-based roots is that "since Mac OS X is BSD based, the ports shouldn't be too difficult. The hardest part, according to Robert Palmer, will be writing the GUI (graphical user interface) front end to make administration easy." My question is, is this likely to happen? Will UNIX developers want to port their applications to an operating system that costs more in hardware and OS software both? Or is the demand likely to come from the other direction -- OS X server admins who want the stability and popularity of established UNIX applications, even if the graphical front-end Mac users have come to expect may be less than ideal? This will doubtless be a big issue for Apple as they tout Mac OS X as a server platform for the future."
nik says: How about "larger installed userbase"? Assume Linux has ~ 7 million users, and the BSD's have about 3 million (both those numbers are on the conservative side). Apple's probably going to ship 10 million or more OS X boxes in the next year or so, and porting most software is going to be no-brainer (particularly if it's already in the Free, Net, and Open BSD ports and packages collections).
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?
Sitting Walrus Blog
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).
"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!
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
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.
Eh...
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
-Colin
It's not really interesting to port "Unix apps" - in the sense of command-line sysadmin software - to OSX. (Mac-based servers will probably be running OSX Server, which resembles NeXT even more and, when you get down to it, is a full-fledged *nix in all but the name. Porting to it should be trivial.)
:)
What's really interesting to port is what we more often think of as "Linux apps" - stuff that you usually run under Gnome or KDE. Galeon is a good example, as are Gnumeric and LyX. This is graphical end-user level software. There is really no good reason not to port it to OSX; in fact, I plan to do some porting myself once it's released. The only significant obstacle I can think of is the graphics toolkit; with that in mind, I think it'd be interesting to begin a project to provide compatibility layers for all the common graphics toolkits - GTK, Qt, Tk (as in Tcl/ or Perl/), and so on - under OSX. Having that, porting your average "Linux program" to the new system would be almost trivial. The programmers in charge would have a much-expanded user base; and the users would be able to run just about anything that shows up on Freshmeat.net. Everybody's happy
To the editors: your English is as bad as your Perl. Please go back to grade school.
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
MunITioN
"A mind is a terrible thing to lose"
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.
Maybe if you compare to x86 hardware (i.e. Emachines). You can pick up a used Imac or a g3 tower for well under $1000, and the G4's are only a couple of grand and outperform x86 hardware in most respects. They're still cheaper than a comparable Sun machine.
Apple has done something really cool... Built a decent server platform that can be administered by total morons. Previously, the only way for idiots to be able to administer a server was to get themselves a copy of NT, and that's not even a decent OS. They're going to make a killing with OSX, and they're going to sell a ton of machines also, especially with the dual G4 machines. How many times have you heard of people going with NT because Unix was hard?
Need Free Juniper/NetScreen Support? JuniperForum
OK, I'm not a super-coder but from my own understanding (and a slashdot article earlier thatn addressed these issues) I'd like to point out that it's a very unfair assumption to claim that GUI porting is easy.
/. article suggested (or at least the comments did) that if M$ released IE for OSX that IE could be ported to X. Not quite.
The earlier
In order to port over a GUI application, you first need to port the graphics libraries and other libraries, which more than likely aren't going to be Open under OSX (correct me if I'm wrong).
If it can be done, I question what software is going to get to OSX. Most good software, IMHO, already has a *nux port (or was designed for Linux *grin*), or has at least planned on porting it. Sadly, it's been my experience that a lot of people (especially the suits I work with) are loath to give up Winblows because of IE, Office, and other memory-hoggin' applications. If it turns out apps can be ported from OSX to *nix rather easily, then my bet is on M$ not writing any software for OSX.
IMHO, this is the exact same reason M$ doesn't make a Linux distro; to do so would require them to open a least a bit of their code, and M$ is scared shitless of the opensource community being able to run their programs/derivatives without paying ungodly liscence fees.
I think the best alternative is not porting over software that companies won't release themselves; rather, we need to let people know we have something better. Porting M$ software and other software that snubs the *nix world does us no favor; it simply tells these companies that their product is so "good" we need it and will port it ourselves. And hell, if the company doesn't like it they can always file charges.
While I admit it would be nice to be able to run every game than runs on a Mac (not sure on the OSX gaming specs) I think we should move towards developing programs designed to run on *nix, not porting over from other OS's. As we continue to grow, companies with enough sense will put out *nix ports. If not, their loss.
Peace,
DranoK
That is not dead which can eternal lie, and with strange eons even death may die.
Shh! Nobody knows I'm gay!
When did Robert Palmer become a developer?
(I'll bet he sits at his keyboard, and has like 10 identical female dancers dancing in sync behind him while he's writing code.)
Hmmm, That would actually be kinda cool.
-- Give him Head? Be a Beacon?
-- Give him Head? Be a Beacon? :P)
(If you can't figure out how to E-Mail me, Don't.
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 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.
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.
/. you will see that Mac developpers make plenty of cash. It has a large userbase that is loyal and pay for its softwares.
:)
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
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
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.
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.
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes
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?
So Linus, what are we going to do tonight?
The same thing we do every night Tux. Try to take over the world!
From www.gnustep.org:
GNUstep provides an Object-Oriented application development framework and tool set for use on a wide variety of computer platforms. GNUstep is based on the original OpenStep specification provided by NeXT, Inc. (now Apple). GNUstep is becoming more and more stable every day and is used in a production environment by several companies.
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.
It's only when we've lost everything, that we are free to do anything...
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...
Lawrence Person (lawrencepersonh@gmailh.com (remove all "h"s to mail)
http://www.lawrenceperson.com/
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
Disclaimer: I have not seen MacOS X from the inside. I have seen Nextstep from the inside. It was beautiful.
Nextstep had one of the easiest and most elegant programming languages I have ever seen. It was called Objective-C and was OO in C done right: Pure C with the Object mechanisms of Smalltalk thrown in. You might have seen part of the ideas behind Objective-C recently: The signal-slot mechanism in the Meta Object Compiler (moc) in Qt has its roots in the Objective-C model, and Gtk ported that to plain C. In Objective-C it is part of the language, no moc or handcoding necessary, and all objects, slots and method invocations use this mechanism.
On top of this, the Next people built an API and tools which really revolutionized programming for me. This was the only programming environment where I actually felt supported by the API and programmed to solve a problem, instead of fighting shortcomings of the system.
The OO toolkits that came with their Objective-C compilers were one of the most cleverly designed collection of classes I have ever seen: By combining components of the Appkit and the Enterprise Object Framework, I was able to built applications which navigated a system of SQL tables, browsed tables and even allowed simple changes in table values in the SQL database - and I was able to do this by simply connecting the components in Interface Builder, no compile necessary for a working application! Of course you could compile and save the result and had a standalone application which worked just as well.
But Nextsteps Objective-C objects had enough metainformation ready that they were loadable and runnable (sic!) in their equivalent of Kdevelop. This is was reusable component software done right can do for you. Talk about fragile superclasses, about Corba and COM. I had all this in 1994, on a 25 MHz 68040 with 20 MB RAM, and it was better than anything that money can buy now.
On top of this, Nextstep delivered a GUI which painted every single pixel on the display with a postscript interpreter. This allowed you to write widgets in postscript, load them into the (possibly running remotely) display server, and run them with a single command. In todays buzzwords that would be equivalent to writing all your widgets in Java, uploading them to your X server once, and have them running up there, instead of sending four million drawing commands each time your want your widget shown. Nextsteps GUI displaying remotely was faster than X even with compression on slow links, because "execute that widget again" is faster to transmit and parse than all these drawing commands, and "your button 17 has been hit by left-mouse-down" is faster on the wire than long lists "mouse-move to coordinates x,y", "mouse-down on x,y" events.
The fact that postscript can do coordinate transformation, font handling, color, alpha channel mixing and several other things right which X still cannot do properly today helped, too.
But enough of the nostalgy. Here is my advice to you: Have a close look at MacOS X native API, at the language, at the object system, at the display system and at several other things. The Next people are extremely bright, and they are still at work at Apple. Unless Apple managed to really fuck up their Nextstep heritage, you have the chance to see a really, really nicely engineered system and you may learn a lot of things about elegance of design, about handling software components, and about OOP outside the scope of C++ and Java.
Do not try to port your code. You won't be doing your code and the MacOS X API a favor. Make your first experiences with natively designed code, and try to forget your Unix and C++ heritage when you make them. Unlearn what you have done previously and relearn programming and OO their way. Try to see the beauty of their way and widen your perspective.
Then come back and review your old work in your newly collected experience. I will find that your have many new and exciting ideas what to do and how to do it differently.
© Copyright 2000 Kristian Köhntopp
Tenon Intersystems has already announced X (as in X11R6.4) for X (as in Mac OS X).
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.
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.
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
--
$x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
$x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
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.)
Information wants to be anthropomorphized.
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.
-- Still waiting for the Nike endorsement
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?
Anyway, my rant on the issue is that sites like MacInsider are touting the fact that the Mach kernel "Has been forged in the fire of open source peer review, etc.", but then they're ripping it out of the open source community and making it proprietary.
I'd rather have someone respond than be modded up.
This is true of the OS, but I doubt that it will be formally enforced with apps. However, I think you are on to something here.
Just as the UNIX culture has an ethic of doing the Right Thing when writing software, mostly centered around maximizing efficiency and portability of code, the culture of Mac gurus have very strong opinions about well-designed code, particularilly in the area of making your user interface logical, simple, and seamlessly consistant with the conventions of the MacOS.
A good example of thier fury was MS-Word version 6.
In spite of the massive hatred of DOS and anything else to do with Redmond, Word 5 was the most popular word processor for the Mac ever. It had been, since the very first version, designed specifically for the Mac, and clung tight to the reccomendation the of GUI cannon that was coming out of Cupertino throughout the late 80's and early 90's.
When M$ came to version 6, they decided that what Mac users really wanted was interoperability with the Windows box they had at work, so instead of adding Word6 features to the Mac version of Word5, they did a crufty port of Word6 for Windows to the MacOS, complete with Windowsy dialog boxes and button bars. Some of it even used the old windows code, with translators copied into the Mac system folder during installation. Even the Word Macro viruses were cross-platform transparent.
The backlash was epic in scale.
Macophiles ourtright refused to "upgrade", and if they did give up their Word5, it was to switch vendors to Word Perfect For Mac or Nissus Writer. Some of them even switched to heavy-duty page-layout apps, like PageMaker or Quark, rather than deal with the steaming pile of crap that Word6 was quickly discovered to be.
Microsoft eventually recovered when they release Office98, but only because they are Microsoft. A small company that made such a huge misstep would probably never be heard from again.
My advice to *n?x vendors who want to reach a wider audience by porting their C app to the Mac platform would be to either bone up on Mac GUI conventions, or else perhaps contact a MUG and find a Mac code geek who is willing to work with you on it.
Information wants to be anthropomorphized.
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
===========
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.
The kernel is not proprietary. In fact, the complete, functional core OS, called Darwin, is open source:
http://publicsource.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.
> 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.
--
Sheesh, evil *and* a jerk. -- Jade
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.
--
Sheesh, evil *and* a jerk. -- Jade
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.
No, Thursday's out. How about never - is never good for you?
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
-Joe
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...
Potato chips are a by-yourself food.
"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.
A Government Is a Body of People, Usually Notably Ungoverned
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?
no sig.
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