Mac OS X 10.2 Technote Released

Etcetera writes "Apple has released their Mac OS X 10.2 (Jaguar) Technote chock-full of useful information about the API and technical changes in Jaguar. Interested parties will find lots of neat stuff in here... including the idea of storing kernel panic info in NVRAM and writing it to a logfile on reboot."

Comments

Check out the BSD section

[Demona]

Linux users should appreciate some of the nice changes in the BSD section. Some are just the sort of window dressing we've come to expect like making bash the default shell, but others such as PAM, and replacing inetd with xinetd, show that Apple is trying to focus just as much on offering a solid, competitive Unix as they are trying to give it a friendly face. (Note: By 'competitive', I mean competing with the current 'best of breed' Linux distributions)

Re:some thoughts

[Dephex Twin]

Are cursors that big really that necessary?

Beneficiaries that immediately spring to mind are children and vision-impaired.

Re:some thoughts

[Wiwi Jumbo]

I've always thought that cursors should be in a vector format and then be scaled to whatever size the user wants.

But then again... no one ever listens to me... :)

including the idea of storing kernel panic info in

[kangolo]

> including the idea of storing kernel panic info in NVRAM and writing it to a logfile on reboot

AIX has done this for years. Another example of what you can do when you control hardware and software.

Horay. Finally automake

[Billly Gates]

After reading all the scary news about HP switching to palidome and seeing IBM already has it. I am strongly considering a mac. As soon as the dying g4 is replaced hopefully with IBM's powerpc I will look into upgrading.

MacOSX is finally turning into a more traditional unix with Xf86 support, now automake as well as some nice speed enhancments. I tested jaguar out at compusa and its a hell of alot faster. Everything loads in a second or two. (or may have seemed fast compared to my pentium700 running w2k.)

Good job apple!

Other gems that are included

[wfolta]

Some other cool UNIX additions:

• The Ruby scripting language is now installed with Mac OS X
• Python 2.1.1 is now installed with Mac OS X
• The tool "automake" is now installed with Mac OS X
• The curses library has been updated to the newer ANSI compliant ncurses library, which supports color and other advanced text attributes as well as offering greatly increased compatibility with applications which rely on having a standards-compliant curses library.

Not bad, eh?

Python in X

[Tar-Palantir]

Note the BSD section includes the fact that Python 2.1.1 is installed with Mac OS X. This ought to make some folks happy (myself included).

Math libraries included, too...

[wfolta]

• A complete BLAS implementation ships with Mac OS X 10.2. The Basic Linear Algebra Subroutines (BLAS) are high quality leaf routines for performing basic vector and matrix operations.
• The LAPACK library ships with Mac OS X 10.2. LAPACK provides routines for solving systems of simultaneous linear equations, least-squares solutions of linear systems of equations, eigenvalue problems, and singular value problems.
• The libm library is now standard compliant. The new math library in jaguar is now IEEE-754 and C99 compliant in double precision. In addition, the new libm is faster than MathLib found in Mac OS 9 and faster than libm in Mac OS 10.1.x.

Thought this was interesting...

[VValdo]

In order to reduce application launch times, the kernel now maintains information about the working set of an application between launches (in "/var/vm/app_profile"). Pre-heat files are meant to be transparent to the user; however, developers who are constantly re-working their applications may find that their pre-heat files are getting large. The files may become clogged with out-of-date profiles on applications who's versions have changed. As a result, developers may find that it is good to clear out the old pre-heat files on test machines once in a while. To do this, become super-user and do a rm -r /private/var/vm/app_profile and then reboot. app_profile is the directory which contains the profile files. The directory is automatically re-created on reboot. (r. 2847332).

Hmm. Wonder if this will slow down my nightly upgrade of Chimera, Mozilla, etc?

W

X11 is not really supported

[g4dget]

Sadly, there is no X11 support in Mac OSX--X11 on OSX requires a separate download. It works acceptably well, but it is not well integrated with the OS. Also, when you upgrade to Jaguar, your X11 installation breaks and you need to reinstall it.

Apple really needs to support X11 officially alongside with Cocoa and Carbon. Vendors of OSX software (e.g., Matlab) clearly want to use it. Users need it for tens of thousands of educational and scientific packages that are not going to get rewritten. Supporting X11 would be very little cost or overhead, and it would make the machines a lot more interesting and attractive for scientific and engineering uers.

Re:X11 is not really supported

[andrewski]

Apple WILL NEVER include or support X11. Why not?

1. X11 apps use a plethora of ugly widget sets, all of which look and feel completely different from one another and from Aqua. There's no way Apple would endorse or implement such a flagrant pile of different UI's on their carefully-crafted OS. Can you name a single X11 app that comes even close to conforming to the Apple UI guidelines?

2. The availability of X11 native on OS X would discourage developers from making their applications at all Mac-like in appearance or functionality, leading to less mindshare for Apple's way of doing the GUI.

Apple is still fighting with application developers to get them to Carbonize their apps. Carbon blows, big time. It's a stopgap solution crafted solely to allow ports from OS 9. (If you are developing a brand-new program for Carbon, allow me to BITCH-SLAP you out of the 80's with the clue stick a few times. ) Apple, and anyone with a brain, knows this. Apple's ultimate plan is to ditch Carbon like a hooker bad case of genital warts. Carbon ties Apple to the Motorola PPC platform which is looking more and more like an evolutionary trichordate (good potential, slow development causes it to be overwhelmed by the competition).

Apple surely won't go out of it's way to deny X11 on OS X, but you can bet they won't include it with OS X v10.3 or or OS X v11 or whatever.

As a side-note, does anyone have a theory on how Apple will name their products in the future once the 10.x numbers run out for them (or they get sick of 10.x)? Mac OS XIV anyone?

Re:X11 is not really supported

[bnenning]

Taking advatange of Cocoa makes your code non-portable.

Wrong. Objective C is supported anywhere gcc runs, and there are multiple free implementations of Foundation (the non-GUI portion of Cocoa). The UI portion of Cocoa is not portable (although GNUstep is getting closer), but then neither is Carbon.

When Alias|wavefront ported Maya to Mac OS X, they had no need for a 9 version, they had no existing Mac code base to salvage, they were starting from scratch. Yet they ended up using Carbon

Possibly because when they began their port, Cocoa projects couldn't have ObjC and C++ source code in the same file. They can now, so there's no reason you can't have a Cocoa front end to your C++ back end (see Chimera for an example).

It's great for little one-shot tools and utilities, but the big boys use Carbon.

Most of the big boys may use Carbon currently, but Cocoa lets the little guys create apps that rival them. See OmniWeb, OmniGraffle, TIFFany, Stone Design, ViaVoice, and many others. Perhaps what you're seeing is that companies writing Carbon apps need many more developers than those writing Cocoa apps.

Re:X11 is not really supported

[g4dget]

X11 apps use a plethora of ugly widget sets, all of which look and feel completely different from one another and from Aqua.

Apple won't stop those widget sets coming to Mac OSX--they'll just get Quartz backends and otherwise behave just like they did under X11. Apple could actually make the situation better by taking control of X11 on OSX, improving it, and standardizing things, as well as by allowing KDE and Gnome to provide native-looking OSX themes.

What this is really about isn't usability, it's about Apple trying to tie developers to their proprietary APIs. But I predict that's a losing battle: Cocoa and Quartz are side shows today--faintly 1980's in their design and without any ground breaking advantage. Most non-Carbon Mac development is happening, and will continue to happen, with C++ wrappers and Java.

Can you name a single X11 app that comes even close to conforming to the Apple UI guidelines?

Gnome, KDE, and many other X11 desktops and toolkits are completely themable and reconfigurable. You can make them look and behave as close to OSX as Apple's lawyers will allow. KDE, for example, already has options to put the titlebar at the top of the screen and choose Macintosh style focus behavior and shortcuts.

The availability of X11 native on OS X would discourage developers from making their applications at all Mac-like in appearance or functionality, leading to less mindshare for Apple's way of doing the GUI.

Yeah, and the lack of availability of X11 just discourages developers, period.

I have heard the arguments before, and my prediction is: Apple is hurting themselves big time by trying to herd developers to Cocoa-based ports. The should celebrate the fact that they have gotten a lot of interest from scientists and engineers and support their (potential) new customers; they can then worry about how to help those new customers and developers to develop Macintosh-y applications using their chosen tools.

Re:X11 is not really supported

[am 2k]

Apple could actually make the situation better by taking control of X11 on OSX, improving it, and standardizing things, as well as by allowing KDE and Gnome to provide native-looking OSX themes.

theme != look and feel

Cocoa and Quartz are side shows today--faintly 1980's in their design and without any ground breaking advantage.

Ok, you just admitted that you've never used them.

Most non-Carbon Mac development is happening, and will continue to happen, with C++ wrappers and Java.

Sure. That's why there is a single email per month on the Cocoa developer mailing lists saying something like "Help! I'm a newbie and I want to learn Cocoa using Java", and two or three people reply "use ObjC". I've yet to read an advanced Cocoa/Java-question there (and I've been on Omni's lists for two years now and on cocoa-dev since it began).

KDE, for example, already has options to put the titlebar at the top of the screen

I'm using it on KDE, it feels like somebody removed the menu bar from the single window application and put it on the top of the screen. Not quite like Mac apps, where you can have multiple windows in a single app.

What about things like extension mapping, drag and drop, pasteboards, services, single mouse buttons, dock icon updates, dock menus, NSToolbars, etc...?

Re:X11 is not really supported

[Draoi]

Requiring people to download X11 source code, fink, and the entire development environment in order to be able to pop up an xterm is absolutely ridiculous.

You don't have to. You simply download the XFree86 package for MacOS X and click on it to install. If you like your X to have all that Aqua gooeyness, download the excellent OrborOSX package & perform a single-click install.

To upgrade to Jaguar, download the new XTerm package update (1MB - whoopee). One click and you're done again!

No rpm -u, no make install, no gcc, no fink, no X11 source, no dev env. Now, how difficult is this??

Re:some thoughts

[Maserati]

Large cursor support

64x64 cursors will also be a boon to those trying to implement a game interface using as much of the basic APIs as you can (always a good idea if you can manange it).

.ttf files now recognized as fonts

This makes it a lot easier to use Windows fonts in OS X. It isn't a big deal, they're just checking off that last box on the list.

Re:some thoughts

[be-fan]

But cursors in current machines are hardware drawn (quite an good performance improvement actually) and current hardware doesn't do vector cursors.

Hoorah for CUPS!

[tm2b]

My favorite change: the printing system was been replaced with CUPS, allowing Mac OS X users with printers from companies who enjoy screwing Mac users (*cough* Epson *cough*) to use Gimp-Print drivers. Hoorah, open source support!

How to install the Gimp-Print drivers is detailed here. It's trivial.

Re:Panic logging

[Macka]

Writing into NVRAM should mean that the data survives not just a kernel panic/reboot, but also a powercycle or warm restart. Store it in (volatile) RAM and there are situations where you could loose it!

[OT] IPSec and OSX

[Junta]

This is a bit offtopic, but is there any projects making use of the ipsec API in OSX to do VPN connectivity? The 'VPN' used in MacOS is PPTP by default, and I would like to integrate an OSX system into the VPN configuration here for free..

the _best_ feature: ktrace works!

[GrumpyOldMan]

Thje Technote fails to mention the best thing about 10.2 -- the kernel is compiled to support ktrace(1). In 10.1, the kernel was not compiled to support ktrace.

For you linux people out there -- ktrace is a little like truss or strace, but it relies on tracepoints in the kernel, rather than /proc. It shows you everything
the kernel is doing on your process' behalf, even things which may not show up as a system call (like signal posting). And following forks actually works.