Slashdot Mirror

Forgetting that both iPhone and Mac can be programmed with C/C++ and OpenGL for games...

Oh, you mean like id games:
http://www.joystiq.com/2009/02/25/carmack-quake-live-on-mac-linux-high-on-my-priority-list/
http://en.wikipedia.org/wiki/Doom_engine "Originally developed on NeXT computers"

Or maybe you meant http://www.stepwise.com/Articles/Business/NuclearStrike.html

There doesn't seem to be a shortage iPhone games...

Plus, Objective-C and Cocoa are Awesome(tm)

I am sorry, I posted the wrong link on Stepwise: You want Freeze Dried Objects
http://www.stepwise.com/Articles/Technical/FreezeD riedObjects.html.

If you haven't used Interface Builder (IB), then you are really missing out. Many people have a difficult time wrapping their brain around the concepts of Interface Builder, but I assure you it is across the board the best GUI builder paradigm yet invented. For a very brief introduction to its concepts, see Hold Me, Use Me, Free Me http://www.stepwise.com/Articles/Technical/HoldMe. html.

In fact, IB should have been named "Object Connector" because it is not a "builder" at all. All IB does is let you instantiate objects, specify their initial state, and define connections or relationships between the objects. You should note that it is equally applicable to user interface objects and every other kind of object including your own custom classes. The configured objects are serialized to either a binary file or an XML file (your choice). The "Test" mode in IB just serializes and then de-serializes the object graph in memory to produce a fully functional system that you can test.

Although Interface Builder has been available since 1988, it is actively developed by Apple and is in fact free along with the rest of Apple's development tools with Mac OS X. Recent additions to Interface Builder have included Key-Value Observing which eliminates al lot of "controller" code from a system and Data Modeler which automates a lot of "model" code.

Steve Jobs used to state that it doesn't matter whether code is hand written or computer written, every line of code is a potential bug and a source for future maintenance. The only way to radically improve programmer and life-cycle productivity is to radically reduce the amount of new code needed to implement applications. IB is a stellar example of the wisdom oh his words. [This is also a huge win for cultural localization...)

Given the extremely rich frameworks of objects (both GUI and non-GUI) that are available from Cocoa, IB's ability to instantiate objects and form connections and relationships between them without any code is a huge win. If you haven't used this technique, trust me: you don't know what you are missing. You will never want to go back!

IB's down side has always been documenting (for posterity) all of the connections and relationships that are specified in IB. IB is improving on that front with XML file formats and data "entity-relationship" modeling built in. There have also been plug-in palettes that improve documentation generation.

Just as a reminder, unlike most GUI builders, IB works equally well with your custom classes and the framework classes. You can build new "palettes" for you objects to provide slick graphical interaction, but the basic connections and relationships capabilities work with all objects with no special effort.

Apple's IB description: http://developer.apple.com/tools/interfacebuilder. html
There is an excellent but shallow Introduction to Interface Builder at http://developer.apple.com/documentation/Developer Tools/Conceptual/IBTips/IBTips.html

I would say that Apple would be better serve their own self interests by writing an application compatibility service for Windows XP

why Java is so suboptimal compared to languages like Objective-C and APIs like OpenStep/Cocoa. I mean Java is like some sort of second infusion of Coffee (and we all know that only green tea is better at the second infusion ;-) ): you know what it is supposed to be but it just doesn't taste like the real thing.

Doubly astonishing so since SUN was co-developing OpenStep in team with NeXT, so they should have known how to design a proper API and what language features are needed for this. Now the Java API is bloated to no end and still incomplete: I miss the virtuosity of the small but feature complete OpenStep API (why aren't there methods like componentsJoinedByString and componentsSeparatedByString or the goodie makeObjectsPerformSelector in the counterpart java.util.ArrayList available? Or just simple things like a constructor like this: NSArray(java.lang.Object[]). Those were only some randomly picked small examples. Not to speak of key value coding or EOF what most of you probably don't know.). I am linking here not to the Objective-C Cocoa docs (here I miss categories most, although I must admit that those would be a potential security issue for Java Applets (that's where Java made it's first steps: in the webbrowser)) but to the Webobjects JavaDoc to show that such stuff is possible with Java. Only god (and the SUN) knows why they did not make it so. In lieu thereof we've got a plethora of collection classes which overlap a lot in functionality. That pattern shows everywhere in the "official" Java APIs.

And don't get me started on WO/EOF vs. J2EE ;-)

exuse my poor english, it is not my native tongue.

regards, sqar

The whole article seemed to culminate in the following information: some guy said if Macs were more popular they would have a worse record than "other operating systems." It seems to be comparing OS X to Linux, but it isn't entirely clear what the baseline is for their eval of Mac OS.X and it also doesn't clarify what exactly makes these OSs different. Also, the web site defacement isn't proof that the person with an unprivileged account acquired superuser privileges to do anything other than deface the web page. I don't doubt it could have happened, but maybe it did and maybe it didn't...

"The only thing which has kept Mac OS X relatively safe up until now is the fact that the market share is significantly lower than that of Microsoft Windows or the more common UNIX platforms.... If this situation was to change, in my opinion, things could be a lot worse on Mac OS X than they currently are on other operating systems," said Archibald at the time.

Also, giving people LDAP accounts on the machine is really cheating. Maybe some noobs get a boner when someone fuzzes the hell out of a box from a local account until they get some fuzz escalated **BORING**. If they really wanted to throw down the gauntlet, then we would see Mandatory Access Control implemented on OS X . The big difference is that the MAC policies would be enforceable at the Mach MK level (on Mach ports, tasks, processes...), and OS X would be the ONLY OS with a security policy interface that could come close to usable for average people.

I disagree.

Certain software that needs access to system-wide stuff, sure. Software that you are installing for all users, sure. Other stuff, not so much.

If software requires admin privileges to install, there's a ton of things that that software could do in addition to just installing the software. Some examples that come to mind are: installing other software such as spyware, trojans, viruses and backdoors; scatterying random hidden files on your drive; f'ing your system in general.

Personally, I don't ever fully trust anyone's software other than my own (and even that is questionable sometimes ;), and giving some arbitrary shareware admin privileges is simply way too scary -- especially when there is no need for it.

To say that Objective-C is that ugly implies that you mightn't have had that much experience with the deeper aspects of Objective-C, or haven't really leveraged them to your advantage. Categories, for example, are a tremendously powerful tool and can be used quite beautifully to logically structure classes. There's other benefits of course, why don't you check out the Wikipedia article on the language and find out? Or if it's just the syntax, there's a good semantic reason why Smalltalk syntax would be advantageous over dot notation, if you have an understanding of how messaging works in Objective-C.

Objective-C dispatch is not really that expensive in any case. There is caching involved, so any costs are countered anyway. With judicious use of static typing as well as making use of dynamic typing, one can take these costs down further.

As in comparison with Java - well, trying to do certain things in Cocoa and Objective-C just can't be done in Java. Have a look at the Stepwise articles Categorically Speaking and Java Categories: A Modest Proposal to see some examples of what I mean.

If you understand the language fully, you'll come to understand why the way it is much better.

To say that Objective-C is that ugly implies that you mightn't have had that much experience with the deeper aspects of Objective-C, or haven't really leveraged them to your advantage. Categories, for example, are a tremendously powerful tool and can be used quite beautifully to logically structure classes. There's other benefits of course, why don't you check out the Wikipedia article on the language and find out? Or if it's just the syntax, there's a good semantic reason why Smalltalk syntax would be advantageous over dot notation, if you have an understanding of how messaging works in Objective-C.

Objective-C dispatch is not really that expensive in any case. There is caching involved, so any costs are countered anyway. With judicious use of static typing as well as making use of dynamic typing, one can take these costs down further.

As in comparison with Java - well, trying to do certain things in Cocoa and Objective-C just can't be done in Java. Have a look at the Stepwise articles Categorically Speaking and Java Categories: A Modest Proposal to see some examples of what I mean.

If you understand the language fully, you'll come to understand why the way it is much better.

I'd recommend you don't waste your time with Carbon, which is the API associated with legacy support. Learn Cocoa instead. Cocoa is the future.

For learning Cocoa, the gold standard is Aaron Hillegass' "Cocoa Programming for Mac OS X", Addison-Wesley, ISBN 0-321-21314-9.

In addition, read Apple's online developer documentation. Just install the developer tools and then point your browser at

file:///Developer/ADC%20Reference%20Library/docu me ntation/index.html

The introductory stuff on Cocoa is at

file:///Developer/ADC%20Reference%20Library/refe re ncelibrary/API_Fundamentals/Cocoa-fund-date.html

For resources check out

http://www.stepwise.com

and join the Cocoa Developer mailing list at

http://www.lists.apple.com/mailman/listinfo/cocoa- dev

other resource links, including book referrals, ar at

http://www.stepwise.com/StartingPoint/Cocoa.html

I'd recommend you don't waste your time with Carbon, which is the API associated with legacy support. Learn Cocoa instead. Cocoa is the future.

For learning Cocoa, the gold standard is Aaron Hillegass' "Cocoa Programming for Mac OS X", Addison-Wesley, ISBN 0-321-21314-9.

In addition, read Apple's online developer documentation. Just install the developer tools and then point your browser at

file:///Developer/ADC%20Reference%20Library/docu me ntation/index.html

The introductory stuff on Cocoa is at

file:///Developer/ADC%20Reference%20Library/refe re ncelibrary/API_Fundamentals/Cocoa-fund-date.html

For resources check out

http://www.stepwise.com

and join the Cocoa Developer mailing list at

http://www.lists.apple.com/mailman/listinfo/cocoa- dev

other resource links, including book referrals, ar at

http://www.stepwise.com/StartingPoint/Cocoa.html

A little Googleing gives us a) the Freescale (nee Motorola) AltiVec Libraries (Login required), which includes (among others) strlen and b) this code fragment and c) a more general description.

Actually, the "import" versus "include + ifdefs" is not a problem. It's not even really a GNUstep problem -- more a gcc one. At one point, they deprecated the "import" (but the support was still there..). Now, the "import" is no more deprecated in the current gcc. So... if you want to use import, go on, it works with the apple gcc and the fsf gcc..

The automatic garbage collection support (using boehm library) in GNUstep is, afaik, only available for -base (Foundation), not -gui (AppKit), although I could be wrong. I must confess that I never tried it, as the retain/release/autorelease garbage collector scheme works well enough (and is very flexible) as soon as you understand it (a very good article about it is this one).

Nah, you're thinking of something else. There have been numerous aborted attempts at creating a next generation Mac OS under a variety of strange code names like Pink, Taligent and Copland.

Rhapsody was the name of the OS [strategy] developed under the leadership of Gil Amelio, it was heavily based on OpenStep (moreso than OS X), hence it's cross platform capabilities. Apple also had a version of the Rhapsody frameworks that ran in NT, which they inherited from NeXT. At that stage, the name for Cocoa was YellowBox, and the Classic environment was called BlueBox IIRC. There was no equivalent to the Carbon frameworks in those early days, which was the subject of much debate.

Steve Jobs became Interim CEO after Amelio's departure in 1997 and killed the cross platform versions of Rhapsody along with the Mac 'clone' industry. About a year later Apple announced the name change from Rhapsody to Mac OS X. They released Mac OS X Server in 1999, followed a year later by the almost unrecognisable OS X Public Beta.

Check out these screenshots, which (in order from top to bottom) show the gradual progression from NeXTstep's multi-column Browser to Mac OS X 10.3's Finder*.

NeXTstep
Rhapsody
Mac OS X server 1.x
Panther

*yes, I skipped the aqua Finder.

When the NeXT cube came out, the crowd I was hanging with didn't take it seriously. Even when the 'fire sale' occured and they got really cheap, everybody scoffed at it. I wouldn't mind having one now, but as a historical curiosity for my collection, and not much else.

When the Sun Starfire came out, the crowd I was hanging with didn't take it seriously. Of course, I didn't know anything about it. I'm guessing the same is true here.

A 1994 NeXT is still sufficiently more advanced (speed aside) in many ways than more ``modern'' computers. For example, I can write a GUI application on the one in front of me in just a few minutes that can be run natively on a m68k (black hardware), x86, HPPA or Sparc processor.

OPENSTEP took it a step further and allowed you to deploy on NT (OPENSTEP Enterprise).

There was a pretty decent market for NeXT where people needed GUI applications written quickly. Consider the following:

NeXT Order of Business.

It's not possiable w/ Mail.app as far as I know, but my solution to this was to change where UW IMAPd uses for imap mail. It works fine, my home folder doesn't get messy, and I don't get junk. I'm too lazy to look up the correct line, but there is an article on Stepwise about it; it's undewr the Pre-Mac OS X10.1 section. I just recommend you put it in ~/.mail instead of Library/Mailboxs as the article says

Back in pre-Alpha, pre-Quartz, when faked screenshots of the upcoming MacOS X were an entire social movement, I put together a fake "faked" screenshot of OS X for Stepwise.com (Solution) that got slashdotted. Lots of fun. Maybe we should do one for Panther...

Sean Luke

Back in pre-Alpha, pre-Quartz, when faked screenshots of the upcoming MacOS X were an entire social movement, I put together a fake "faked" screenshot of OS X for Stepwise.com (Solution) that got slashdotted. Lots of fun. Maybe we should do one for Panther...

Sean Luke

Back in pre-Alpha, pre-Quartz, when faked screenshots of the upcoming MacOS X were an entire social movement, I put together a fake "faked" screenshot of OS X for Stepwise.com (Solution) that got slashdotted. Lots of fun. Maybe we should do one for Panther...

Sean Luke

Have you tried EOF (part of WebObjects)? It uses an extensive caching structure and cascades modifications. It's not completely transparent though, but I doubt that any package can provide that given the complexities of such a solution. This explains how to extract EOF for use in a pure Java app.

This is a great tutorial detailing the steps to get postfix going on mac os x. It's a bit outdated (probably written for 10.0 or 10.1) but it's not very difficult to figure out what to do for jaguar from it.

Also, O'Reilly's Building Cocoa Applications is excellent for the beginner, although I wish they would publish AppKit & Foundation in a Nutshell for a good off-line reference.

Some other good references:

• http://www.stepwise.com/
• http://macdevcenter.com/
• http://www.cocoadevcentral.com/

If you're going to put any effort into setting up a mail server on your Darwin/OS X machine, then put in a little extra work and switch to postfix. And lucky for you, Graham Orndorff has put together a comprehensive tutorial on postfix (also imapd, fetchmail, and stunnel) for OS X on stepwise. This is a man who background includes 3 years at NeXT and 4 years as mail architect at WebTV. In other words, you should trust his opinion. And he even writes great documentation!

If you're going to put any effort into setting up a mail server on your Darwin/OS X machine, then put in a little extra work and switch to postfix. And lucky for you, Graham Orndorff has put together a comprehensive tutorial on postfix (also imapd, fetchmail, and stunnel) for OS X on stepwise. This is a man who background includes 3 years at NeXT and 4 years as mail architect at WebTV. In other words, you should trust his opinion. And he even writes great documentation!

In a nutshell, this article is saying, "Waaa! It's hard to be a real programmer!!"

Who didn't already know that?

For an anecdotal refutation, there are more interface tweaks available than I have time to explore.

Specifically regarding themes/schemes/skins/etc: It's a little bit of a bummer that Apple has never sanctioned them, but I can say after twiddling with WinAmp over on the dark side, that most interface remakes are absolute crap anyway. It's a perfectly windows-like waste of time sorting through the thousands of available skins to find the one skin that's an actual improvement to the original.

Of course, your mileage may vary.

In case you thought it was a serious article, please peruse your friendly Mac OS file archives.

Here are some places to start:

MacUpdate
Apple
Mac OS X Apps
Stepwise
OSX Page
Versiontracker

Such as? There are command-line apps, which "normal" users don't use directly, and then there are GUI apps that users launch by double-clicking. They may be Cocoa, Carbon, Classic, or Java, but they all appear the same (except for classic apps not having the Aqua interface).

Quartz is an enormous resource hog and rather sluggish.

Not as much of a problem in 10.2. Quartz is just slightly ahead of the hardware, like the original Mac UI was in 1984.

The Cocoa API requires lots of manual storage management and manual layout management.

Not at all. Cocoa uses semi-automatic reference counting; it's not quite as transparent as Java's garbage collection but it's far better than the nonexistent memory management in C/C++.

it was a nice idea in 1985, now we have better systems

Objective C is the best language for Cocoa development; use it and you'll see why. But Java is fully supported for both Cocoa and standard Java apps.

In the medium term, they might even be well advised to drop Quartz and Objective-C

Um, no. If anything they should be funding GNUstep.

I think Apple won't be able to keep up with Gnome, KDE, Ximian

Keep up? They've already done what those efforts have failed to do: produce a Unix-based system usable by mortals.

While you don't need Mac OS X Server to do this, the same resources will apply. I would recommend the OS X Server mailing list, or the X Server Admin Guide. Both are good sources of info for doing just this kind of thing.

Also take a look at some non-Apple resources: AFP548.com is consistently the most current, and has a question and answer bulletin board; there's also StepWise, an oldie but goodie.

Hope that helps, and good luck.

if there's such a nice API and software development tools, why was nothing ever developed with it.

Because plenty of stuff *has* been developed with it. You're just ignorant of them. For example, it has been heavily used in the intelligence industry and on Wall Street. And I'm sure you've probably heard of Mac OS X, right? Guess what the primary development platform is. You should check out Softrak and the peanuts FTP archive some time too. And maybe the OMNI Group and some others. Is there as much software as there is for Windows? No. Is that because MFC is a superior development platform? Pffffft. It's because Microsoft has the marketing muscle and lock-in advantage (and an awful lot of luck thrown in for good measure).

And why is every application that was developed as part of it so primitive and un-user friendly.

You've never used any of this stuff, have you? There are some quite attractive and usable applications out there. GNUmail is very nice, for instance, and was developed primarily by one author in a very short period of time. Are there poorly designed UIs as well? Of course. But that's the fault of those who design. And that happens everywhere--UNIX, Windows, Mac OS, BeOS, etc.

Is it just a coincidence that it was a brilliant platformed developed by people with no design sense.

I find it to be quite elegant looking. But at any rate, I was talking about the API. Y'know, stuff like Array and String classes and responder chains. Stuff you don't actually "see". How it actually looks is not set in stone. That's why Mac OS X looks completely different but is built on the same basic classes as OPENSTEP or GNUstep.

You bash the platform for a number of purported deficits, and yet you claim (and demonstrate) a complete lack of knowledge about it.

I suppose I should just let it go, but what really frosts me is how you seem to feel that you are far too "l33t" a badass unix stud for any toy system to satisfy, and yet you obviously aren't willing to invest even the tiniest effort to investigate the actual facts. Do you even realize how asinine that combination of arrogance, ignorance, and ineptness really is? Would you think it appropriate if someone trashed Linux/Perl/GPL/whatever with the same pathetic incompetence?

In a nutshell, though, the answer is yes. Perl? Yes. GCC? Yes. X11? Yes. MYSQL? Yes. Apache/PHP? Yes. Ruby? Yes? POV-RAY? Yes. GIMP? Yes. NetHack? Yes. Whatever does not come preinstalled is readily available not only from Apple, but from the standard distribution channels for the specific tools. In fact, if you look around you will see that most popular apps have OS X on the regular build tree -- run the nightlies all you like.

Anyone who is interested in learning more about the Unix infrastructure of OS X might want to check out the following starter list:

Darwin - Darwin is a complete open-source BSD distribution. Apple makes both the source and extensive documentation available for free. It does the same for a number of other major apps, such as the QuickTime Streaming Server. This does not include the source to things like the Aqua and the user-experience GUI, but it is everything you would get in a regular Unix...because it IS a regular Unix.

Apple Developer Program -- For the price of a free registration, you can download the latest tools (e.g., gcc3, ProjectBuilder), APIs, and sample code directly from Apple. These tools include "generic" Unix favorites as well as a number of extremely powerful OS X-specific tools.

Fink -- The major source of convenient ports using the Debian dpkg and apt-get tools. There are other systems, but Fink makes installing things such as X11, KDE, Gnome et al a snap and has over a thousand of the top apps ready to roll. Don't forget Fink Commander, which gives you a convenient Aqua interface to the Fink tools.

O'Reilly's OS X Developer Center -- O'Reilly needs no introduction, but their OS X developer articles and resources are an excellent source of information for developers of all levels.

Stepwise -- Scott Anguish and the Stepwise folks cut their teeth on NeXT, but they continue to offer gurudom to the OS X community. They regularly detail how to use the latest ports and patches, and know a ton about Cocoa and Mac development.

MAc OS X Labs -- Though their focus is on using OS X in higher education, they are a decent resource for OS X-related development and integration.

Scott Anguish has an article on stepwise.com that shows you how to build OpenSSH yourself. He also suggests that you use the Apple-supplied "nobody" account for the purposes of privilege separation, as well as doing so in his instructions.

I don't know if Apple configures their update similarly, but I'll bet they do.

Scott Anguish has an article on stepwise.com that shows you how to build OpenSSH yourself. He also suggests that you use the Apple-supplied "nobody" account for the purposes of privilege separation, as well as doing so in his instructions.

I don't know if Apple configures their update similarly, but I'll bet they do.

So ... since it's slashdotted ... and I can't read the article to make any funny/amusing/trolling comments about it ... I won't make any comments whatsoever ...

1) Precompiled packages for MacOS X based on a nice package manager (PHP 4.1.2 is available):

http://fink.sourceforge.net

You can also use the instructions in this article to easily compile version 4.0.6 with the options that you want.

2) Civilization III is known to be slow (also on a PC). Have you installed the latest patch and disabled quartz text? You can also try to make an image of the CD (with disk copy) and use that, that should speed it up a bit as well. Optimizing your HD is also advisable. I've heard about a guy having smooth gameplay with the same machine that you have, so it's certainly possible.

You probably want to check out: http://www.stepwise.com/Articles/Workbench/2001-03 -24.01.html and probably a bunch of other articles at www.stepwise.com. I personally found compiling PHP on Mac OS X much easier than on Linux, but that was probably because I was more experienced at stuffing around with apache modules.

2) I bought Civilization III for Mac OS X. I have a 677mz G4 processor with 512 MB of RAM, and the damned game is so slow its almost unplayable. That's simply unacceptable. I can't remember the last time that I cursed so much at a game. It doesn't matter if companies port their software to Mac OS X, if the port is practically unusable.

You have to carefully port games to OS X or you do hit huge performance problems (what is fast on OS 9 is slow on OS X and visa versa in a lot of cases). However, Macs are not gaming machines by any stretch of the imagination.

It is worth noting that in general use Macs perform just as well as PCs. I have a 400Mhz TiBook and a 1.2Ghz Athlon with the same amount of RAM in each and in general use I can't tell the difference in performance. Even when compiling stuff there doesn't seem to be any difference. Games are faster on the PC, graphics work is faster on the Mac. The casual home user should ignore the speed of the computer altogether these days.

But if you tell me you didn't buy a Mac because you were too cheap, rest assured that you won't get invited to any of my parties. I'd rather have no scotch than cheap scotch ;-)

I completely agree. It's not that hard to save up a bit of money for things, just learn to budget a little.

It doesn't have a nice, clean, compact menu for switching windows, like the one in the top-right corner in MacOS 9 or the GNOME panel.

The standard-issue Web browser is Internet Explorer. I don't think I need to spell out why this is a problem.

Classic is slow, slow, slow, and crashes a lot. Kids, don't use this at home.

If something bad were to happen, and the UI froze up (which it did quite often, because everything is so slow), it's a little hard to start killing processes, because there is no Ctrl-Alt-F1 or similar to get to a console. (Linux rules.)

Tcsh. 'Nuff said.

You can't open the terminal and run a GUI binary by typing in something like /Applications/SomethingOrAnother.app.

When I tried to switch back to MacOS 9 on bootup, it did something strange to my disk and I had to reinstall everything from the CDs that came with the machine.

Installing a patch from Apple's Web site left me with a broken OpenSSH that can't talk SSH2. Trying to connect to an SSH2 server with it will cause it to crash.

Their Java virtual machine is broken -- for some reason, jEdit does not exit cleanly if Cmd-Q is used (and yes, the jEdit developers looked into this problem, and were unable to come up with a solution other than not using Cmd-Q).

Software Update goes through windowsupdate.microsoft.com. And it didn't work.

Apple has the gall to charge me money for an upgrade to OS X 10.1 to fix all of these and other problems that shouldn't have been there to begin with.

Did I mention it's slow and crashes a lot?

For technical books/articles on MacOS X, see

DevDepot
MacTech
O'Reilly
Stepwise

Apple hasn't responded as of yet (Thursday, early evening, EST), but Stepwise already has step-by-step build instructions for OpenSSH 3.1 for OS X. Pop over to this page on their site, follow the instructions, and you're good to go.

At home, I run fetchmail, UW Imap/pop3, and postfix. (Some excellent instructions for installing it are here at Stepwise), Image Magick, Gimp, and some other Open Source programs on OS X. I also use BBedit and Microsoft Office X. (And I can say that Entourage is a far superior program to the one I have to use with Windows.)

The good news: Nothing broke. 10.1.3 didn't rewrite any mail settings, so all of my mail continued to come in/get sent out just fine.

The bad: Still no focus-follows-mouse, multiple desktops, or the ability to connect to my wife's printer on her Windows 98 box.

I did have a problem with Samba for a little bit (I have another computer running Win98 I use just for games playing). Once I turned off the SMB service and turned it back on, it worked fine.

Some of these things comes from a former KDE user (ie: focus-follows-mouse, etc), but overall, since it didn't break anything, I'm assuming all went well. As person who used Linux 90% of the time up until last week, OS X is still surprising me by all the little nice things they put in.

MacOS X is actually an OS on top of an OS. The basic operating system is Darwin, which is based on BSD, though its kernel is based on Mach - this is the same relationship between Solaris and SunOS. If you are interested in a more detailed explanation of Mach and Darwin then check out the link here.

Darwin will run quite happily without MacOS X, though the reverse is not true. In fact there are people doing just that and using X-Windows instead. One thing that make Darwin different from other BSDs is that it is an OO OS, for example the I/O allows one driver to inherit functionality from another driver ( single inheritence, though ).

MacOS X as the previous poster pointed out comes bundled with all sorts of APIs than adds all sort of features than makes it more than just a fancy windowing environment. So as I said before MacOS X is an OS on top of an OS.

To protect my pathetic bandwidth on the local server, the article is also available here on the graphics server. That should cover off any bandwidth issues.

Troy's article really does highlight the use of these environments for tools behind the scene's.. there is an older article on this as well that is linked from Troy's document.

To protect my pathetic bandwidth on the local server, the article is also available here on the graphics server. That should cover off any bandwidth issues.

Troy's article really does highlight the use of these environments for tools behind the scene's.. there is an older article on this as well that is linked from Troy's document.

Not, it's not the emulayer (if there is one). People test filters, which exist outside of the Adobe app. They execute their own code, duh! In Photoshop's case, Intel's engineers MMX'd the filter code so they would get trounced so badly.

Do you really think a dual 1ghz p3 system is 50% slower than a 733mhz G4?

Having one sitting on my desk, yeah... I have used dual P3s at work for various data crunching (and compiling, which I do a lot of everywhere), and damn this baby shines :) Only a dumb-ass would say it's faster across the board. Steve Jobs demonstrated the first 733 MHz machines 'matching' a 2 GHz Pentium 4 at a single Photoshop task way back when the 2 GHz didn't exist. You don't really see any other vendors brave enough to step up to the plate and provide any convincing counter-arguments...

When AltiVec kicks in the performance boost is truly mind boggling. Several parts of OS 9 are written in AltiVec... I think OS X is still a work in progress in that area.

A little OT now, but one of the reasons why OS 9 is so damn fast (when it's not doing heavy multitasking) is that Apple learned a lot about the speed of their OS when they had so many components running in 68k emulation. Take those bottlenecks and apply altivec to them...

AltiVec isn't just for graphics. strlen can get quite a nice boost.

Not, it's not the emulayer (if there is one). People test filters, which exist outside of the Adobe app. They execute their own code, duh! In Photoshop's case, Intel's engineers MMX'd the filter code so they would get trounced so badly.

Do you really think a dual 1ghz p3 system is 50% slower than a 733mhz G4?

Having one sitting on my desk, yeah... I have used dual P3s at work for various data crunching (and compiling, which I do a lot of everywhere), and damn this baby shines :) Only a dumb-ass would say it's faster across the board. Steve Jobs demonstrated the first 733 MHz machines 'matching' a 2 GHz Pentium 4 at a single Photoshop task way back when the 2 GHz didn't exist. You don't really see any other vendors brave enough to step up to the plate and provide any convincing counter-arguments...

When AltiVec kicks in the performance boost is truly mind boggling. Several parts of OS 9 are written in AltiVec... I think OS X is still a work in progress in that area.

A little OT now, but one of the reasons why OS 9 is so damn fast (when it's not doing heavy multitasking) is that Apple learned a lot about the speed of their OS when they had so many components running in 68k emulation. Take those bottlenecks and apply altivec to them...

AltiVec isn't just for graphics. strlen can get quite a nice boost.

Answers from an OSX user.
1. The default console is ksh. However, building and using bash is a realtively simple process. Check out StepWise for instructions. In fact, check stepwise for general "How do I..." OS X answers.
2. Most of the 'standard' tools are there. vi, top, apache, sendmail,php. you can build most UNIX apps with a simple recompile and few changes. Most of them have already been built for OSX. AS for the directory structure, yeah, it's pretty similar. User permissions, /root, /etc, it's all there. However...
3. Apps are kinda tricky in terms of where they install. Many Unix apps will install into something like /usr/bin but most Mac apps will install in the Applications directory, with user settings in the User/yourname directory. It's a compromise for those of us moving from OS9.
4. The toolkit is amazing. I've never seen anything like this simply given away. there are about 25 applications, megabytes upon megabytes of documentation, anything you could need to start developing applications. Want to build an interface for Aqua. It's there. Want to simply create a command line app. go for it! It's defintiely focused on the Cocoa developer. As I've not developed much with GTK/Qt, i can't make an apt comparison.
5. you comment about openness, etc. is pretty much right on. The low level and system level system is open, as the Darwin project. the UI level stuff is closed, including the PDF screen display, alpha blending, 3d widgets, etc. However, the hooks are very well documented and pretty easy to follow for developers. It's pretty easy to see how everything builds in layers.
What's nice about what apple has done is build on open technologies rather than try to enforce proprietery extensions, like Microsoft and their directX or ClearScreen. Apple's response has been, OK, we'll use OpenGL and PDF for our display. These are fully open, cross platform technologies that we're building on, not ramming down your throat. This is repeated time and again when looking at OS X and other Mac Apps. It's kind of nice to see how innovative you have to be when you don't own the world...

That's my bit. Enjoy.

Two resources I've found useful in Cocoa programming are stepwise.com and O'Reilly's Mac Devcenter.

But what do I know.

Part 1 and

Part 2.

In summary: Unix + lazy installers = bad

F-bacher

Part 1 and

Part 2.

In summary: Unix + lazy installers = bad

F-bacher

Yes, pax is a complete piece of crap. The good folks over Stepwise warned about problems with it a long time ago (scroll down to the heading "Installer.app"). Apple blithely went on using pax anyway.

Perhaps after this disaster, Apple will finally realize they should maybe start using something more robust for their packaging system on X.

It is worth noting that the Mac OS 9 version of the iTunes 2.0 installer (yes, they are still updating the Mac OS 9 version of iTunes) did not exhibit the problem, as it doesn't use pax. It uses Apple's old "tome" installer archive format instead.

I already posted one reason, heres another (since Slashdot rejected it as newsworthy; apparently it ain't 'stuff that matters')

Scott Anguish of Stepwise is reporting on a security exploit that allows any user with Desktop access to gain 'root' access.

Fun fun fun. 'Course, as one person put it, now I can empty my trash without logging out.

(tig)