Advocacy
Dojo (HowTo)
Reference
Markets
Museum
News
Other
Myths
Press
General
Hack
Hardware
Interface
Software
Standards
People
Forensics
Web
CodeNames
Easter Eggs
History
Innovation
Sightings
Opinion
Martial Arts
ITIL
Thought
|
I have received a few questions about Mac OS X (mostly from Eirik Iverson), so I decided to make a pseudoFAQ (Frequently Asked Questions). These are just my opinions, and I don't represent Apple -- but I do read most of their publicly disclosed information. So take these "answers" for what they are worth -- one Developers semi-informed, unofficial ramblings.
Do OS X Server AND OS X both support SMP?
To my understanding OS X Server does not, yet... but since no one currently sells an MP card for the Mac (in the way the question is being asked), it doesn't matter much. Most people that are serving will never get to the point where they need multiple processors anyway -- so I'm not that concerned for today, and it will certainly scale tomorrow.
The bigger question is will OS X and OS X Server support SMP in the near future (like when OS X is released), and is Apple likely to have MP machines in the near future? Apple said last WWDC (Developers Conference) that they would have MP machines, and that MP was going to return to the Mac (in a big way). So not only would I expect that OS X will have MP, I'm pretty sure that a version of OS X Server will soon too, and it is likely that Apple will be selling MP machines in the not too distant future as well.
From Rhapsody to OS X Server to OS X, were any features lost? If so, significance?
Yes, some features lost -- and some features added, and some just changed. The biggest thing lost is "official" hardware support of some older models, and Intel support. This doesn't matter if you are buying new hardware -- but it is very annoying if you are trying to stuff OS X Server on older hardware (and have a 7500 lying around waiting to be used as a server).
Does Linux offer any features that the first version of OS X will not? If so, significance?
Significant? Not that most USERS should care about. In fact, the point is that the majority of usage of LINUX is as a server -- and OS X Server is easier to install and use (from what I've seen) so is likely better in that niche (as a turnkey solution).
If you are an IS guy with UNIX experience, then there are advantages to having LINUX, like being able to compile your own tools and so on -- but not many, and most are for building solutions other than what OS X Server offers.
So OS X Server is a solution. Linux is a tool to create solutions. OS X is going to be a user solution -- and Linux is not really anywhere near there yet. But there are certainly likely to be some geeky acronyms, tools and features that both OS's have that the other does not.
OS X on x86 hardware, how do software applications have to be modified?
Apps run on top of OS X Libraries (YellowBox, or maybe Carbon) on top of WindowsNT on a PC (x86) -- and there may be some questions about that too. But my understanding was that there was not much a porting effort to make Apps work back and forth (especially for YellowBox). For now, I wouldn't bet the farm on Apple's support for this.
Simply "porting" Unix applications to OS X should be easy, but what about the difficulty of making these applications Mac-like in their appearance and use?
There are two distinct markets for OS X -- clients and servers.
Clients
Unix people make pretty ugly client software, in that most are geeks and design interfaces for the top 1% of Power-Users, if they care about interface at all. Most care about complexity and power far more than actual learnability or usability. If you are in that minority (that needs those power features) UNIX can be great. For most of the rest, it is just annoyingly complex and you can spend more time learning packages than you gain from using them.Getting those people to port to Macs (or getting them to see the error in their ways), or getting Mac programmers to create Human Interfaces on top, is no easy feat. On a good package the UI code can be 50 - 80% of the total work. (On most UNIX apps, it is probably 10 - 20% of the effort expended, or less). So porting UNIX apps and redesigning it for users is not usually a trivial task.
OS X Client (OS X) will probably be hurt for a while with bad ports from UNIX -- just like many early DOS programs corrupted the Mac (for the first few years of the Mac). But most bad Apps died out when ones with better interfaces replaced them. Mac users generally understood UI, and bought Apps with better interface, and the programmers learned (or left). So software Darwinism helped push better UI's on the Mac and on the world at large. Things like Lotus-1..2..3. could only survive on the PC / DOS and flopped on the Mac, as did many lousy interfaces like it.
Servers
For the server market the UNIX stuff is very powerful. There is far less interface code in most server apps, so it is easy to port them. Since interface is far less important to server Apps (since it is usually just used for setting up parameters, and then it runs in the background) it won't matter much if they do have bad interfaces. So Server Apps and tools will port pretty easily, and require fewer changes. And the Mac is fairly weak in some of these areas, so they can add lots of value.
What about porting NT applications to OS X; what are the issues, pros/cons, challenges?
Cross platform development is easy to do if you design well, and difficult to do if you design poorly. This is why it is generally easier to port UNIX apps around than NT Apps. NT Apps are usually fairly proprietary and design around Microsoft thinking (which is pretty proprietary and nonstandard). UNIX people tend to think about porting issues, cross platform and abstraction, and do a far better job of design. (It is just interface where they have issues).
So you can do the math yourself. You can port from NT to other OS's, including Mac OS or OS X, if you design well. You don't see that many ports for reasons. The Apps that came from elsewhere (like UNIX), are more likely to be ported first -- but there will certainly be a few NT ports.
Why is BeOS relevant? Its software and user installed base is so small. And, why does BeOS need Apple's permission to gain access to G3 specifications, is this due to a licensing agreement among Apple and the manufacturers of PowerPCs IBM and Motorola?
BeOS is not relevant. They make a nice vertical OS, that can be cool in servers and embedded Applications. I find no use for it on a Mac. My Mac has more tools, a better interface, and is pretty darn fast for 99 of what I need speed for. So while I understand coders want to play, and that it could do some nice serving stuff, I have no use for BeOS anyway.
I think Be has realized that Mac users are sensitive to interface, and so they are more ignoring that market now. Also they are not getting much capture -- so they are sort of trying to play to the Wintel crowd -- which may not be a bad plan.
Does BeOS need Apple's permission? Nope. They could easily borrow from the LINUX code or other sources. So the reason they are not supporting the G3s is more political than anything else.
When an application operating in OS X's Blue Box crashes, closing all applications running in Blue Box, would OS X automatically (or a control panel option) restart Blue Box and perhaps the applications and even the documents that were opened (with some obvious losses to the documents)?
I doubt it. The MacOS could to a lot of logging, and figure out where things are... and then when you kill it (or it dies) it could bring you back -- but then there is a strong chance it would die again, or that you are no longer interested in doing what you were doing before. So why?
Multiple cores, either initially or later featured in G4, do they behave largely like multiple symmetric processors, requiring no special programming to exploit them?
There are many, many ways to implement multiple cores in a processor. (Shared Units, only parallelizing threads, completely independent processes, SMP, AMP, etc.). But it is most likely that these sub-processors will be implemented so that they behave like completely independent processors -- meaning SMP support would be nice.
What would be the strategic disadvantages to porting Mac OS X to the x86 platforms? (Think convolutedly. I hope I spelled that right.)
I think the bigger question is what are the strategic advantages.
Apple wastes a ton of time (and money) porting to the x86. Because of the lack of true standards in the PC world, they would have a tough time making things work better than PCs do now. It would cost a fortune to get lots of drivers written, and because the size of the market is so small (to start with), Apple would have to do it ALL themselves. Because it would be new, they would likely have some "burn-in" delays, and some bugs to work -- in the mean time the PC advocates would be tearing OS X apart (they seem to fear change by and large). And there are serious problems with inferior subsystems on the PC.
So you'd end up with an OS X experience that wasn't as good as the Mac. You'd have to make your developers work harder (to get cross platform apps), you'd have support nightmares. And every flaw in the Wintel versions would be used as an attack against the PPC version.
What for? A small percentage of PC people that would actually consider using it, and might actually migrate?
That doesn't seem like a good RIO (Return on Investment). Better to focus on making one good platform, than 2 OK ones. If Wintel ever gets a platform standard (like they've tried for 4 years to do), like the Platform99 standard, or platform00 standard, etc... and they can simplify the scope of the Wintel platform (Like eliminate the ISA slot, fix the IRQ limits, get rid of old style Serial and Parallel, and focus the platform into something, anything) then Apple should consider supporting it -- but not before. Maybe Merced Migration will be a good time... but let the Apps and OS X environment mature on the PPC for a few years before pushing the move.
Someone mentioned that rewriting drivers may be as or more problematic as carbonizing, how significant is this?
Very significant -- to those that have to rewrite drivers.
By Apple reducing the platforms they are supporting, they radically simplify their problems. This is one of the reasons they want to reduce the number of machine/models they support.
Of course I won't give them a free ride on this. Apple said they would support 75/7600, 85/8600, 95/9600's and maybe even PowerBook 1400's (certainly 3400's). I would actually be willing to get involved in a class action suit to force Apple into supporting those machines, officially. But we have to wait and see what they do first. Realistically, it probably wasn't technically a promise, just a "strategic direction" -- but if people made purchases accordingly, I do think Apple should have their feet held over the fire until they deliver. Many bought machines expecting they would be supported in the future -- and Apple shouldn't drop the ball, even if it is only supported in a later release.
So that leaves 3rd party companies. There may be some way for older drivers to work for a while (maybe not) -- I haven't read everything on this yet. But most should be updating for other reasons. Individually drivers are not that hard -- especially if Apple has driver templates and Driver Kits to help and especially if the drivers have been written well in the first place. If the drivers weren't written well, then it is probably time to rewrite them anyway.
Are firms such as Iona building development tools to aide in the transformation of COM plus software from NT to a CORBA environment like OS X (Is OS X CORBA? What else?) ?
CORBA is neat for large database stuff (client-server, distributed Apps, etc.) and for big IS/IT departments -- but it realistically isn't going to effect most users. So the question is more how important it is in the high end? There are a lot of opportunities to make money by offering such tools in the Mac arena, and porting these interfaceless tools should be pretty damn easy, so I imagine there will be such tools offered. Isn't capitalism wonderful?
With all the potential server applications that can be ported to OS X, should Apple try to control, guide, and or stitch together everything into a uniform tapestry? Or would that be making a mistake that Microsoft may be making with Windows 2000?
There are about 10,000 bigger mistakes in Microsoft/Windows (and Windows2000) than trying to create a "uniform tapestry". So the question doesn't make much sense in that regard.
Personally, I think Apple should do more to push for a standardized User Interface (and better user experience) -- but there aren't much rewards for doing so -- so I imagine Apple will just punt (and ignore) that issue, and leave it to the market. Apple has bigger battles for now, and those are usually losing PR-Wars, and Steve Jobs is very PR-concious.
To get people to comply you basically have to point out that the baby (3rd party apps) are ugly. Even when true, they don't appreciate it. Do you think Lotus want's to have Apple telling them the truth that Notes is an ugly hack on the Mac? How do you think these companies will respond when Apple attacks their interface and "noncompliance"? That is airing dirty laundry in public, and the Mac is better with these ugly interfaces that without the Apps at all.
What are IS/IT Managers, decision-makers thinking about MacOS X? Would they be willing to put it in a mission critical position or wait for perceived bugs to worked out first if ever?
99% of the IS managers will wait -- which is the smarter thing to do in mission critical. Most will wait much further than they need to, which is the not so smart thing to do.
- Sometimes IS does some testing WHILE they are
implementing cross over strategies -- while they are
doing some porting (and test deployment) in the process.
They do this when they have faith in the
company/technology and believe that things WILL
eventually get worked out. (They do this for Microsoft
and WindowsNT even when it has been 5+ years waiting for
things to "eventually" get worked out).
- Sometimes IS uses "waiting to see" as an excuse to delay forever, or until people forget about it.
Lets hope there is a lot of the former, and less of the latter. The IS types that have been bought by Microsoft (with MSE's and so on), and are true NT believers (see zealots), will not be convinced no matter what Apple does. But there are many that are not happy with the broken promises of NT, and there are many trained on UNIX and other solutions, and will see OS X Server (and OS X) for what it is, a pretty damn good alternative to proprietary technologies that is Microsoft.
Is it true that yellow box is primarily exploited via Objective C (also Java has been added but how significant)? Is it true that overall few programmers speak Objective C?
YellowBox right now has an ObjectiveC interface, and Apple is adding a Java based one.
Yes, few programmers currently speak "ObjectiveC", but ObjectiveC is just a few (nice) Object extensions to the C languages (and most know C). It is cleaner, and far simpler, than C++, and it takes a lot less time to learn. I picked ObjectiveC up (the basics) on one weekend -- and I'm not as much of a hotshot Coder anymore. Programmers will whine about a new Syntax, because that is what they do. Ignore them. If they can't pick it up and be using it in a couple of days, they should be fired for incompetence or for being too narrow minded to grow (who needs dinosaurs?). I heard the same whines when going from Assembly-to-Fortran, anything-to-C, C-to-C++, adding frameworks, and now to go to Java. If they can't pick up a new syntax in a few weeks (Maximum), then they aren't very good programmers.
Java is a better Syntax than C++ overall (and at least as good as ObjectiveC), in that people have the potential to make far less errors, and produce more (and better) code. But it takes a little control away -- and programmers whine about that, because that is just what they do. Ignore them. If they can't pick it up and be using it in a couple of days, they should be fired for incompetence or for being too narrow minded to grow (who needs dinosaurs?). I heard the same whines when going from Assembly-to-Fortran, anything-to-C, C-to-C++, adding frameworks, and now to go to Java. If they can't pick up a new syntax in a few weeks (Maximum), then they aren't very good programmers.
Do you see a pattern there. Any Syntax is a tool. If people are too stupid to stop using a hammer to drive screws, then I don't have much tolerance for them. I've had to change Syntax at least 5 times in my career (and have used about 20+ languages) -- it isn't that hard, despite the complaints the lazy will have to use their brains again. Usually, they kick and scream and whine, and attack, and threaten to quit, and then learn it -- and then suddenly become complete converts and are insufferable supporters that will never admit a flaw in their new preferred Syntax.
Neither Java nor ObjectiveC cures world hunger, or even all programming issues -- but it is just a Syntax. I think more and more people will program in Java in the future. YellowBox has the potential to be the best framework for Java -- far better than Swing, the stuff Sun has done so far, and anything else I've seen so far. Compiled Java for YellowBox would make a pretty damn compelling development environment, and a competitive advantage for Apple and the companies that chose to use it.
But YellowBox (whatever Syntax) won't always be practical for most because of legacy issues -- so for the next few years I see a LOT of Apps (the majority of Apps), for OS X, will still be Carbon-based. If I was designing a product for 2 - 3 years down the road (release schedule), I'd certainly consider seriously at Java and YellowBox.
I'd be far more serious if Apple (at the TOP, see the man in Steve Jobs office) would stop being so quiet about YellowBox, and publicly state that Carbon *AND* YellowBox have a future at Apple (not just the former). The silence (going on a year now) about ANY YellowBox strategies from Apple has been deafening!
Conclusion
Hope this Q&A pseudo-FAQ answered some questions for people -- at least it tells them where I think Apple is going (in the YellowBox and OS X areas). If people care, maybe I'll add to this over time. The worst part about playing prognosticator is that on some of this I will be wrong (I just hate that).
Normally developers are pretty informed about future company directions -- like OS plans. They need to be so they can adapt their plans to Apple. But Apple has been annoyingly close-mouthed about OS X, OS X Server and so on. In some ways this is good, since Apple can market by surprise. But for developers (and IS staff) trying to make long term strategic deployment and development decisions, this is bad. Apple is losing business because many plans have lead-times measured in many months (or years) -- and most developers are flying blind. Shutting developers out is not a good way to get them enthused or developing. We'll certainly know more at Apple's WWDC (World-Wide Developers Conference) in May, but I'm hoping the attitude changes around then as well.
|
