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

some thoughts

[GreyWolf3000]

Straight from the beast:

Large cursor support, for cursors up to 64 by 64 pixels, has been added to the QuickDraw APIs. (r. 2827587).

Are cursors that big really that necessary?

True Type font files with the extension '.ttf' are now recognized in Mac OS X. (r. 2823850).

Funny--I never thought they were needed. Fonts have always looked better on Macs...nothing wrong with support I suppose.

CUPS has been integrated into Mac OS X. (r. 2849589).

This is nice...ought to make life easier for those of us with Macs on the *nix-based LAN. Looks like Apple is headed for more interpolation. Especially with all the rumors of an Intel port of OSX flying about :)

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

[GreyWolf3000]

I think the big issue is the color contrast moreso than the size, right? Since eyes track the movement and that movement is most easily by one color moving through a starkly different one. Though the size might be a big deal...well I'd imagine their r&d funds came up with a good reason for it, and they know more than I do :)

Re:some thoughts

[Yarn]

maybe in preparation for higher resolutions (dpi) which will be becoming more mainstream soon.

Re:some thoughts

[Dephex Twin]

I think the big issue is the color contrast moreso than the size, right?

Well, sure, that might be true. And maybe for eyesight-impaired a bigger button really wouldn't help much-- that was just a guess of course... but as for the kids thing, I still think the ability for a larger cursor would be useful.

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... :)

Re:some thoughts

[Anonymous Coward]

Also games that want a custom pointer (ie, crosshair)

Re:some thoughts

[lemkebeth]

Wanna bet?

Big cursors do help the low vision impaired, (like me).

Try standing 200 or 300 feet from your monitor and get back to me.

Re:some thoughts

[Toraz Chryx]

I suggest you email that to Apple, surely they have a "suggestions box" email address?

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.

Re:some thoughts

[ealar dlanvuli]

I'll expand his point

the dpi of your monitor is probably effectivly 96, but suppose someone has a 600dpi monitor (damn that would be expensive..). When your GUI "set up" the monitor, it would compile the cursors into a bitmap for the apropriate dpi.

The video card would still get fed a bitmap yes, but it would only require one cursor for all future screens (think ttf fonts)

Re:some thoughts

[KillerKane]

Someone correct me if I'm wrong, but wasn't Apple the first one to make a cursor that modified itself to contrast with whatever it was mousing over? I think it might have been a function that was built into Quickdraw, and executed in hardware from very, very early on.

IIRC, this was one of those fine details that made their GUI stand out from the others in the eyes of the computer press (and computer professionals) at the time.

Re:some thoughts

[Anonymous Coward]

True Type font files with the extension '.ttf' are now recognized in Mac OS X. (r. 2823850).

Funny--I never thought they were needed. Fonts have always looked better on Macs...nothing wrong with support I suppose.

Macs have used truetype fonts as their native format for as long as i can remember. What is this "nothing wrong with support?" you speak of?

Re:some thoughts

[Anonymous Coward]

My, but we are insensitive to those less fortunate than ourselves aren't we? What's wrong? Don't want the HANDICAPPED to use computers too?

Re:some thoughts

[dair]

The cursor doesn't modify itself, however its mask is one pixel thicker than the image - to give you a white border around the black arrow.

The border is invisible when you're over something white like a window's contents, but lets you pick out the black interior of the cursor when you mouse over something darker.

If you use a black border around a white interior, moving the cursor over a black background will make it seem to shrink slightly - the border will vanish, and you'll be left with just the interior. Doing it the other way round means the cursor always has the same appearance.

-dair

Re:some thoughts

[Saint Fnordius]

Are cursors that big really that necessary?

In addition to the vision impaired and ungodly resolution points already mentioned, it's good for Hollywood-style interfaces. Means you'll see more Mac OS X in TV shows and movies. Or games with funky cursors.

True Type font files with the extension '.ttf' are now recognized in Mac OS X. (r. 2823850).

Funny--I never thought they were needed. Fonts have always looked better on Macs...nothing wrong with support I suppose.

Mac and PC TrueType fonts were always close enough that you could convert between one or the other. Apple has just made the conversion step unnecessary.

Re:some thoughts

[Yarn]

Sun's old OpenView used to have all its cursors as fonts. Great fun changing it. Well, a little fun at least.

Re:some thoughts

[Morth]

The cursor doesn't modify itself, however its mask is one pixel thicker than the image - to give you a white border around the black arrow.

The arrow cursor didn't modify itself, but the I-beam one did (all the way up to os 9). It's as simple as this:

cursor mask underneath result white 0 white white white 0 black black white 1 white white white 1 black white black 0 white black black 0 black white black 1 white black black 1 black black

Re:some thoughts

[Morth]

Oh damn, hit submit instead of preview... oh well, point is a black cursor pixel with a 0 mask inverts what's underneath.

Re:some thoughts

[Junks Jerzey]

Are cursors that big really that necessary?

When screen resolution is high enough, yes.

Re:some thoughts

[Lars T.]

And people with a higher resolution display. Maybe the next Cinema Display?

Re:some thoughts

[Lars T.]

And the scaling algorithm is already there for icons. And I'm not even going to mention Quartz Extreme.

Re:some thoughts

[be-fan]

I think it might just be easier to make a giant 256x256 cursor in that case. Display resolutions go up slowly enough that "cursor scaling technology" really isn't something to bother about :)

Re:some thoughts

[SlamMan]

We'll the .ttf font cam e in handy already, when somebody need an odd cyrilic file opened that used its own font. from the pc world. *Poof* Worked like a champ.

Re:some thoughts

[kwerle]

Not that I do, but if you have a display that's around 4000+ / 2500+, those 64x64 cursors start to look about right. Smaller ones are nearly impossible to see.

Re:some thoughts

[Gorbag]

Gee, and I thought children could see BETTER than us old farts. ;-)

Re:some thoughts

[billDCat]

There is a list of contact info at http://developer.apple.com/contact/ although they didn't seem to include a feedback address. When OS X first came out, there was a web page expressly for this, but I can't find it anymore. I did find some discussion forums at http://discussions.info.apple.com/ which would probably be your best bet for submitting ideas.

Re:some thoughts

[Anonymous Coward]

and it's ugly!!!

icons should be saved similarly, I hate nothing more than having giant pixels just to be able to view stuff on my TV.

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:Check out the BSD section

[NighthawkFoo]

Wow. I'm really impressed with the work Apple's putting into its UNIX subsystem. This gives me yet another reason to purchase that iBook I've had my eye on. :-)

Re:Check out the BSD section

[Anonymous Coward]

xinetd is hardly "best of breed" -- it's had one security hole after another.

The original BSD inetd (particularly the one in OpenBSD) is a far more secure program. The xinetd code is REALLY UGLY (look for yourself if you want a real shock).

foo

Re:Check out the BSD section

[Anonymous Coward]

I found some of the libc changes amusing at best.

"You mean they didn't already have those functions?!"

Re:Check out the BSD section

[MalleusEBHC]

The default shell is still tcsh, not bash. Read more closely:

The bash command shell is now installed with Mac OS X, and has replace zsh as the default /bin/sh (r. 2809843). For people who prefer bash, you can switch over easily and you don't have to install it on your own now.

Re:Check out the BSD section

[opk]

Some are just the sort of window dressing we've come to expect like making bash the default shell

I don't see that as particularly being an improvement. They would have been better off updating to a more recent version of zsh. It would make a more efficient /bin/sh because the dynamic modules mean that none of the interactive functionality would be loaded when running basic shell scripts.

The only reason bash is the default shell on Linux is that it is official GNU shell and nothing todo with whether it is technically any good.

Re:Check out the BSD section

[Macka]

> I don't see that as particularly being an
> improvement. They would have been better off
> updating to a more recent version of zsh

Except that there are millions of bash users out there who are already very familiar with it. I've never met anyone who's ever used zsh. Mac OS X is meant to be for mass appeal, so it makes sense to use well established technologies where they have the choice to do so.

Re:Check out the BSD section

[opk]

> Except that there are millions of bash users out
> there who are already very familiar with it. I've
> never met anyone who's ever used zsh.

Familiarity with the shell used as /bin/sh is not so important as the Posix subset of either shell is much the same (tcsh remains the default interactive shell). And if you are going to go by familiarity, I know more people who are familiar with the Korn shell from commercial UNIX variants than with bash. Apple could have licenced ksh from AT&T and possibly only didn't on the grounds of cost.

It's a pity if you don't know anyone who's ever used zsh. It's extremely powerful and allows me to get things done much more quickly than in the days when I used tcsh.

Re:Check out the BSD section

[benedict]

This was gone over endlessly on the darwin
mailing list. I was somewhat resistant myself.
In the end, though, the winning argument was that
zsh has some bourne shell incompatibilities, even
in sh emulation mode.

Re:Check out the BSD section

[Anonymous Coward]

Zsh is the shit. Everyone I know uses it, even on our macs.

Re:Check out the BSD section

[opk]

It might have been useful if some of these "Bourne shell incompatibilities" were reported to the zsh mailing lists so they could be fixed. I've tried to find what they are by searching apple's darwin lists without success. Though I have come across a few comments where someone has misunderstood something like word splitting on variable expansions which is an area where zsh will faithfully emulate the bourne shell when invoked as `sh' or asked to emulate sh.

Apple's use of zsh 3 for /bin/sh resulted in one very obscure incompatibility being reported by the autoconf people and that had long been fixed in zsh 4 and was easy to work around.

Re:Check out the BSD section

[Macka]

> I know more people who are familiar with the Korn
> shell from commercial UNIX variants than with bash.

That includes me :-) Korn shell would have been my first choice too.

> tcsh remains the default interactive shell

I know, and that's another reason I'm happy bash is on there now. tcsh & csh I avoid like the plague.

isn't this nice

[prichardson]

I think it's excellent that Apple isn't afraid to talk about the technology they use. If Microsoft talked about the crud they put into their OS, people would be able to make WINE a good alternative

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!

Re:Horay. Finally automake

[Anonymous Coward]

From what I hear, the new DDR G4s are fairly nice. However I'd still like Apple to get some sort of post script coprocessor for quartz. Heck, NeXT cubes had those.

Re:Horay. Finally automake

[dfj225]

I have also considered purchasing a mac when I get my next computer. If you knew me, this would be a shocking statement as I have always hated macs. Well, I still dislike the old "fruity" colored ones and any Mac OS = 9, but OS X 10.2 has shaped up to be really sweet and the idea of having a Unix system that actually works, is awesome. Plus, the PowerBook G4 has everything i could want in a notebook. Hopefully by the time I have $$ to afford a comp, G5s will be out (or whatever apple decides to use)

Re:Horay. Finally automake

[Lazaru5]

Finally? It has been since day one. The addition of bash and automake, etc doesn't make it _more_ traditional. If anything it's less.

I'm not against the inclusion of Bash (though finding out that /bin/sh is a copy of the Bash binary is hugely disturbing [It was a bad idea when it was a copy of /bin/zsh too. /bin/sh should be Bourne and nothing else. That's tradition for you.]) or automake (though the autotools suite is mindfucking bloatware) or any of the new things that have been added. But they're all non-traditional, but still very good or necessary (automake) additions.

The only difference in the Unix layer is an updated FreeBSD base, userland and libraries.

Re:including the idea of storing kernel panic info

[Chanc_Gorkon]

Yep! Was going to post it but since you did I won't. I just covered that when taking some AIX training. This feature isn't revolutionary but it is a good idea. You save all of that last minute what caused the kernel to panic stuff so you can then forward it to IBM and see if it's a kernel issue or whatever. I really think that Apple will choose the IBM chips. Those who think they will go down the X86 path are mistaken. IBM makes some of the best servers I have ever seen on every platform including X86 machines.

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?

Re:including the idea of storing kernel panic info

[Stele]

IRIX as well, at least for the past 10 years.

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.

Re:Math libraries included, too...

[am 2k]

In addition, the new libm is [...]faster than libm in Mac OS 10.1.x.

That's not hard to do, since there was no libm in 10.1 (dunno about Jaguar).

Re:Math libraries included, too...

[Anonymous Coward]

The collection of functions understood as "libm"
(sqrt, sin, cos, etc. etc.) live in /usr/lib/libSystem.dylib
on MacOS X. This is the case for Jaguar, 10.1.x, 10.0.x,
PB, DP4, ...

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

Re:Thought this was interesting...

[Hes Nikke]

i could see mozilla and chimera etc having a button in there prefs to do this :)

Re:Thought this was interesting...

[foo12]

Are you really that comfortable with having your web browser able to do an rm -rf as root?

Re:Thought this was interesting...

[Phroggy]

Oh come on, most of the Mozilla developers mean well! What's the worst that could happen?

(kidding!)

Re:Thought this was interesting...

[foo12]

Heh. One little hole in the scripting engine.... *shudder*

Re:Thought this was interesting...

[Hes Nikke]

hmmm... good point... maybe an rm -f * but even that.... *shudder*

BIG cursors...

[dnorman]

... come in handy when driving REALLY high resolutions. It's pretty easy to lose the standard cursor, so it would be nice to have a BIG cursor when using a fancy schmancy 48" Cinema Display or something like that.

Re:BIG cursors...

[NighthawkFoo]

I can imagine that one of those would be useful on one of those 4000x3000 video wall composite displays.

Re:including the idea of storing kernel panic info

[g4dget]

You don't need NVRAM--kernel panics don't result in a loss of dynamic RAM contents. Just write the data into a known chunk of RAM. Of course, on PCs, the BIOS may clear that, but that's a problem with the BIOS. The technique is much, much older than AIX.

Another reason to love my new iBook

[Anonymous Coward]

I never gave Apple's stuff a second thought until OS X ... but bringing up a nice, friendly shell on [splutter...cough] a Mac, of all things, was a mind-bending experience.

Long story short, I waited until 10.2 came out and pulled the trigger on a shiny new iBook. A week and a half into it, I couldn't be happier. Jeez, they even include a developer tools disc. Cool!

Re:Another reason to love my new iBook

[o_kenway]

You could be me! I too just got a shiny new iBook with X.2 - I would never have even considered a mac before OS-X. Only had it 6 days but already I am much happier than I was with my Vaio.

Re:Another reason to love my new iBook

[Anonymous Coward]

Same here: always worked on NT.

Got the wife a brandnew portable: she wanted -gulp- a Mac?!
Bought her an ibook, and now she's gotta kick me out of the way to get to it. It is Sooo cool. Love that unix!

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

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

[andrewski]

Oops! I accidentally hit submit. My completed post is the other one.

Re:X11 is not really supported

[good soldier svejk]

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.

The only thing I noticed breaking was xterm. I downloaded the source and recompiled it under gcc 3.1 without incident. No need to reinstall XFree86.

I agree it would be nice if Apple bundled XFree86. However, installing it is not hard. Fink aside, you can get an OS X binary package from the OS X Gnu guys.

Re:X11 is not really supported

[good soldier svejk]

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

They like to say that (or used to anyway) but I don't see how it is possible. Many developers have custom interface elements (sliders, dials etc.), refined over many years to have very precise behaviors. Cocoa can't replicate these behaviors; no widget set can. If Apple dropped Carbon we could kiss apps like Digital Performer goodbye. Porting it would be prohibitively expensive for a small company like MOTU.

Re:X11 is not really supported

[Hes Nikke]

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?

have you looked at any java apps on OS X lately? they use aqua, but, as you stated above, they don't follow apples UI guidlines!

i don't have a clue how x-11 is done, but if it is anything like java then apple might be able to aquafy all those x-11 apps, and they'll be just as good^H^H^H^Hbad as java :)

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.

i agree, make those x-11 developers work to make there apps work on OS X, either port it, or include directions and say all over them "this looks nothing like aqau because we are lazy bums - thanks for your money"

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

i don't see carbon ever going away, it would be like microsoft killing the 16-bit windows API - it's there so that you can run your older software. not only that, but carbon is used when porting from Windows and (dum dum dum) X-11 apps to Mac OS X, you can't exactly port from windows to cocoa. (though it's been done, Quake III for OS X is a cocoa app! well, it's a BSD app with a cocoa front end) classic otoh is going to be just like WINE, it'll work, if you've got Mac OS 9

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.

that would be insane, apple is now shipping the most widely distributed Unix in the world! why would apple want to piss off the unix switchers? (i'm sure there are more then windows switchers!)

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?

i'm sure that they will continue to call it Mac OS X for the next couple of decades, it'll just be Mac OS X 11.0 etc.

Re:X11 is not really supported

[Phroggy]

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?

I'm hoping for Mac OS 11, and I'm hoping we don't see it for a good long while. I want to see at least 10.3, 10.5 and 10.6 first, and I want each one to be as significant an improvement as 10.2 was over 10.1.

Re:X11 is not really supported

[Anonymous Coward]

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.

Spoken like someone with no experience in this area.

There will never be a major cross-platform GUI application that uses Cocoa. Taking advatange of Cocoa makes your code non-portable. Any major software developer that has a large amount of cross-platform GUI code will have to use Carbon or face rearchitecting their code around Cocoa. Case in point: 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, not Cocoa. Why don't you go "bitchslap" them, and they can smack you back and explain why using Cocoa for what they are doing is a stupid idea.

Cocoa is the Visual Basic of Mac OS X. It's great for little one-shot tools and utilities, but the big boys use Carbon.

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

[Anonymous Coward]

X11 consists of only the most fundamental functions to draw pixels to the screen (or buffer, or whatever). Things like lines, dots are about all you get. You can use graphical tool kits, such as MOTIF, QT, GTK to abstract much of that work, and thus make your life easier. All tool kits have a distinct look and feel, and many like GTK and QT, and later versions of MOTIF are themable, offering infinite possibility in customization.

There's simply no way to "aquify" an X11 session, with the possible exception of using an Aqua like tool kit when programming, or use an Aqua theme for your toolkit. The problem with this is: Apple has copyrights on all of the Aqua UI elements, and using a toolkit or theme based on real Aqua graphics would quite likely result in a cease and desist letter from Apple's attourneys.

Either way, its' not gonna happen.

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

[andrewski]

Your point is? I think it'd be great if you could just run X11 apps in OS X. So do a lot of other people. That isn't going to change reality, though. Steve wouldn't ever include X11. If people need to port their app to OS X but can't or won't port the UI to Aqua, nobody is stopping them from including XDarwin in their installer.

Carbon is useful for what it does. However, just as nobody develops Win 3.1 apps anymore, people shouldn't be developing carbon apps. Cocoa is, truly, in all aspects, far superior.

Re:X11 is not really supported

[andrewski]

Spoken like someone with no experience in this area.

Whoa! How exactly is Cocoa any less cross-platform than Carbon? Cocoa is quite cross-platform, when you consider GNUstep. Carbon only ever has and only ever will run on Mac.

You obviously have never heard of FrameMaker, Illustrator, or the host of other apps that ran on Next back in the day.

I suspect that you were trolling anyway, given your anonymous post. Nice one.

Re:X11 is not really supported

[g4dget]

The only thing I noticed breaking was xterm. I downloaded the source and recompiled it under gcc 3.1 without incident. [...] I agree it would be nice if Apple bundled XFree86. However, installing it is not hard.

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. That is both way beyond either the capabilities or patience of most scientific or engineering users.

People who haven't already switched to Windows are on UNIX workstations for a reason. If Apple wants them as customers, it is not sufficient to come out with a prettier and more robust version of Windows--they need to take workstation software standards seriously. BSD was a good start. X11 is the next step.

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:X11 is not really supported

[Anonymous Coward]

"Carbon blows, big time. It's a stopgap solution crafted solely to allow ports from OS 9. [...] 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..."

Apple doesn't seems to think like you! They did re-write the Finder (the file browser application) in Carbon for Mac OS X. iMovie, iTunes rely on Carbon. And the most important, QuickTime now rely on Carbon. Look at QuickTime for Windows, it use an (incomplete) re-implementation of the classic Mac toolbox to work. In fact, I remember hearing an Apple engineer saying that Carbon was partly based on the Windows abstraction they made of the Mac Toolbox! Doesn't seems so tied to the PPC to me!

Another important point is that you can now mix Carbon and Cocoa in the same application on Jaguar. To do that, Cocoa event now use part of the Carbon event manager to get user input...

So, no Carbon equal no Mac OS X!

Re:X11 is not really supported

[pudge]

Just about every "fact" you state in your posts is incorrect.

1. To be supported is not the same as to be included. X11 is supported on Mac OS X. Mac OS X does have X11 support. To say otherwise is incorrect. Apple itself does not offer X11 support, but X11 runs just fine on Mac OS X.
2. X11 did not break in 10.2, only a few programs that run in XFree86 broke. The only one I am aware of is xterm, and you don't need to reinstall X11, you just need to install a small fix for xterm.
3. There IS NO lack of availability of X11 on Mac OS X. If a developer is discouraged by something that isn't true, that's his problem, I guess. You can keep saying it, but it isn't remotely true.
4. No one has to download X11 source, fink, or any development environment to use X11 on Mac OS X. You download the XFree86 installer (plus the updater for your Mac OS X version). You double-click it. You click a few buttons. You're done.
5. If a scientific or engineering user can't download XFree86 and click "Install", then perhaps they shouldn't be using computers. It's not at all difficult to install or set up. Matlab is also not included with Mac OS X, and I don't hear people complaining about that. Matlab is certainly no easier to install than XFree86 is.

Re:X11 is not really supported

[Lars T.]

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.

That was his point: The UI portion of Cocoa is not portable.

There are cross-platform UI libs that work on Windows, and Carbon/Classic MacOS (and even X Window), but not (AFAIK) for Cocoa. So unless you want to wait for GNUstep to finish, no cross-platform apps for you. Your list of "rivaling" Cocoa software is a good hint, how many of those are cross-platform?

Re:X11 is not really supported

[tokki]

X11 just stinks. Why would Apple want to move back ten years? That's why NeXTSTEP (the basis of OS X) developed their own GUI, because X11 was and still is a horrible UI, with a mishmash of Band Aids and hacks trying to get it to look and kind of act pretty.

If it's just X11, all the widgets would be ugly and awkard compared to Aqua. If they ported KDE and/or Gnome, then they'd have even more control panels. One control panel for Aqua fonts, one for KDE fonts, one for Gnome fonts, one for GTK themes, etc. It'd be unmanagable and ugly.

I say good riddance to X11.

Re:X11 is not really supported

[g4dget]

theme != look and feel

What's your point? I didn't claim they were "equal". Theming is part of making applications look like OSX applications. The "theme" lets you adapt much of the visual appearance of an application to OSX guidelines, the "interaction style" lets you adapt most of the behavior. And the rest is a bit of programming to make X11 apps fully conforming to Apple's guidelines, running through an X11 server.

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.

I own several Macs and have written some smaller Cocoa applications to see how much it had changed from NeXTStep. I have also used Objective-C on-and-off since the mid 1980's.

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

Drag an drop and clipboards are not only supported by X11 toolkits, they could be mapped transparently by the X11 server for the most common uses. Services can be supported with a small extension to the toolkit. Most toolkits already have support for arbitrary remapping of mouse actions, and that mapping can default for single-button mice, just like it does for native apps. Dock icons can be supported automatically. NSToolbars don't look or feel substantially different from any other kind of toolbar. Etc.

More generally, providing an X11 server for windowing doesn't mean that an application absolutely can't access Carbon or Cocoa. Quite to the contrary--by supporting X11 officially, Apple could define X11 equivalents for any Apple-specific desktop functionality, just like Gnome and KDE already do for their desktops.

I'm using [Mac style] 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.

It's the same on both desktops. For example, you can only have a single window open with OSX "System Preferences", while you can have multiple windows open with KDE's Konqueror.

What it comes down to is this: people can and will write lots of Cocoa-based applications that don't conform to Apple guidelines. They already have, in fact. Much of that will happen through C++ frontends to Cocoa libraries.

Supporting X11 will simply let more scientists and engineers get their work done and give people more choices for the software they want to run. If Apple doesn't support it, fewer people will be using the Mac and fewer useful GUI apps will be available for the Mac. And that's not a good thing.

Re:X11 is not really supported

[kalidasa]

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?

[Theory] Apple Mac OS X 10.0-10.9 (Oh-ess-ten ten-point-nine); then Apple OSX 11.0 (Oh-ess-EX eleven-point-zero).

As for X11, I had no problems installing XFree86 several different ways on my OS X 10.1 Mac; the sort of folks who are going to use X apps for Mac don't need to have an Apple-annointed way of doing it.

Re:X11 is not really supported

[Anonymous Coward]

"Mac OS XIV anyone?"

Viva El Norté!

Re:X11 is not really supported

[am 2k]

And the rest is a bit of programming to make X11 apps fully conforming to Apple's guidelines, running through an X11 server.

And who will do the programming (which has to be done on a per-application basis)?

I own several Macs and have written some smaller Cocoa applications to see how much it had changed from NeXTStep.

Ok, then why do you negate features ObjC and Cocoa provide, which enable small companies like Omni to compete with Microsoft?

Drag an drop and clipboards are not only supported by X11 toolkits, they could be mapped transparently by the X11 server for the most common uses.

Like copy/pasting rtfd? Or sound?

Most toolkits already have support for arbitrary remapping of mouse actions[...]

Most ain't all of them. You think Apple will provide rewrites or modified versions of all of the toolkits (like 10? 20?) available?

NSToolbars don't look or feel substantially different from any other kind of toolbar.

So I can right-click on any toolbar and reconfigure the icons in it dynamically? And those settings are preserved? Strange that I didn't notice that in vlc's text-only toolbar.

It's the same on both desktops. For example, you can only have a single window open with OSX "System Preferences", while you can have multiple windows open with KDE's Konqueror.

And clicking on the konqueror icon in the dock brings all its windows to the front? (not mentioning the fact that there are two konqueror icons in the dock when doing that)

What it comes down to is this: people can and will write lots of Cocoa-based applications that don't conform to Apple guidelines. They already have, in fact.

Not conforming to the guidelines in Cocoa means changing the default behavior, which doesn't apply to X11-apps.

Supporting X11 will simply let more scientists and engineers get their work done

Those should be able to install XDarwin without Apple's help.

btw, was one of the first developers to work on XDarwin, so don't think I dislike it. I think there are places where it belongs to, but Apple's default install ain't one of them.

Re:X11 is not really supported

[g4dget]

And who will do the programming (which has to be done on a per-application basis)?

By whoever wants to make their application or toolkit conform with Apple guidelines. And, no, it doesn't have to be done on a per-application basis in most cases.

So I can right-click on any toolbar [... lots more if-buts deleted ...]

You already can't in many native Macintosh aplpications. Macintosh applications already don't conform to Macintosh guidelines.

You are setting the bar higher for X11 than for Quartz. Many people don't care. Many users don't care either. My parents (who use Macs) doesn't care. Many developers won't conform no matter what you do.

Supporting X11 as another API in addition to Cocoa and Quartz will just give developers more free time to work on conformance.

Not conforming to the guidelines in Cocoa means changing the default behavior, which doesn't apply to X11-apps.

If you believe that merely using Cocoa APIs makes your application conform to Macintosh style guidelines, I have a bridge to sell you.

[Scientists and engineers] should be able to install XDarwin without Apple's help.

Even if I can, why should I bother? So far, for me, Mac OSX has made a nice replacement for Windows machines, but it is way more hassle than UNIX or Linux workstations for scientific work.

btw, was one of the first developers to work on XDarwin, so don't think I dislike it. I think there are places where it belongs to, but Apple's default install ain't one of them.

Apple can do whatever they like. But if they want to become a good alternative to UNIX and Linux workstations, as they advertise themselves as being, they must support UNIX and Linux standards more fully. Until they do, OSX will largely remain an OS for home users, students, and some artists, a nice alternative to Windows, but not much more.

Re:X11 is not really supported

[ikekrull]

If Apple will never ship X11 with their machines, why does my IIfx happily run X11 apps on the Apple-supplied X Server integrated into A/UX?

Actually, i find it rather humorous that my IIfx circa 1990 features UNIX/Mac integration pretty-much on par with what is shipped with OS X.

In fact, the IIfx (40 Mhz 68030) boots about as fast and opens terminal windows and other apps way faster than my 550 Mhz TiBook (550 Mhz G4).

Obviously the machines are in different classes and the G4 is doing much more than the IIfx, but it constantly amazes me how much slower doing even the simple things (opening a terminal window with a bash prompt in it) has become.

In fact, i use the IIfx quite a lot as it provides a cheap and usable X-Terminal with more character and a much quieter fan than my assortment of x86 boxes.

Sure, A/UX was never a mainstream OS for Apple, but I wonder what might have been had Apple not abandoned the 'UNIX way' all those years ago.

Re:X11 is not really supported

[wchin]

Now this is just insane. I've used A/UX on a Mac IIfx. There was almost _no_ integration between the Mac and the UNIX sides. You were basically running the equivalent of take-over-the-screen Mac OS Classic environment in a relatively hostile and non-standard UNIX host. There was no Cocoa. There was no Carbon. There were no Mac OS GUI applications that actually were UNIX processes. There wasn't any UNIX API exposure to the Mac side. So don't talk about "pretty-much on par" integration.

the G4 is doing much more than the IIfx

Ah, yeah. The two aren't doing the same thing. That's like complaining that Enlightenment doesn't run as fast as twm. Plus, you're also talking about some disk I/O performance related things. Let's see... the high performance SCSI disk (for the time) in your IIfx was how fast? The laptop ATA drive in your G4 PowerBook is how fast? Hmmm... not much difference is there?

In fact, i use the IIfx quite a lot as it provides a cheap and usable X-Terminal with more character and a much quieter fan than my assortment of x86 boxes.

You can build a cheap and nearly silent x86 box. Really.

Sure, A/UX was never a mainstream OS for Apple, but I wonder what might have been had Apple not abandoned the 'UNIX way' all those years ago.

Of all things, A/UX is and was not the beacon of the future.

Re:X11 is not really supported

[g4dget]

that would be insane, apple is now shipping the most widely distributed Unix in the world!

I think there are good reasons to doubt that. In web statistics, Linux usually is twice as popular as all Macintosh platforms combined (pre-OSX and OSX). Even on the desktop, OSX is probably a fraction of Linux system, and a small fraction of total UNIX-like systems.

Re:X11 is not really supported

[g4dget]

To be supported is not the same as to be included. X11 is supported on Mac OS X.

To me it is. You obviously understood what I meant. Redefining terms doesn't change the fact.

# If a scientific or engineering user can't download XFree86 and click "Install", then perhaps they shouldn't be using computers.

It's not that simple. Even if it were that simple, it's a headache. I don't have to download and install the window system for my UNIX or Linux workstation--why should I have to do it for my premium-priced Mac?

Altogether, my MacOSX machines are a lot more work to maintain than my Linux machines. That's not the way to get and keep professional users for Apple.

Re:X11 is not really supported

[pudge]

To be supported is not the same as to be included.

To me it is. ... Redefining terms doesn't change the fact.

I am not the one redefining terms. :)

If a scientific or engineering user can't download XFree86 and click "Install"

It's not that simple.

You're right, it's not. You have to type in your password (one would hope one would know this), select a language (one would really hope one would know this), then click Next a few times, before clicking Install. My bad. Excuse me while I snicker.

Even if it were that simple, it's a headache.

... ? If X11 were included, it would be on the Developer Tools CD. This is no more difficult than installing from the Developer Tools CD. I'd say it's even easier, because the installer is smaller and faster.

And heck, it is less painful to get it running on Mac OS X than any Linux box I've ever used. Even though it's part of the default install, Xconfigurator by itself always takes a lot more pain than XFree86 does on Mac OS X, which is merely clicking a few buttons. No configuration required.

I don't have to download and install the window system for my UNIX or Linux workstation--why should I have to do it for my premium-priced Mac?

Because the premium-priced Mac already comes with a far superior windowing system, and very few people will ever use X11 on a Mac.

Altogether, my MacOSX machines are a lot more work to maintain than my Linux machines.

Altogether, I think you are a troll. That statement makes no sense, and you've not done anything to back it up. You said a lot of incorrect things about X11 not being supported, and being difficult to install. Even if you want to redefine "supported" to mean "included," it still doesn't come out to "a lot more work" because it is so easy to install. Anyone who knows their own password and what language they speak can do it. I am not sure if that includes you, or not, but none of the rest of us seem to have headaches installing it.

And not for nothing, but your spelling could use some work. There's no such thing as UNIX or MacOSX, it's Unix and Mac OS X. That's not a spelling flame, just a helpful tip.

Re:X11 is not really supported

[Anonymous Coward]

Have it your way. In the unix world we are comfortable with programming on one unix and do "very minor" changes to port it to other unixes. Guess you and apple don't want to be part of that.

Re:X11 is not really supported

[g4dget]

Because the premium-priced Mac already comes with a far superior windowing system,

Too bad it doesn't run most of the scienctific and engineering software people use. Heck, it doesn't even run Matlab--for that you need X11.

You're right, it's not. You have to type in your password (one would hope one would know this), select a language (one would really hope one would know this), then click Next a few times, before clicking Install. My bad. Excuse me while I snicker.

Yup, a gearhead like you would snicker. Most people find the idea of downloading a 53Mbyte package, installing it, setting it up to auto-start at startup, figuring out DISPLAY settings, and all that daunting. And when you are done, you end up with a flickering, sluggish, and bloated implementation of X11.

If Apple wants to make MacOSX an easy-to-use UNIX workstation alternative, they need to make X11 applications as easy to start up as double-clicking on an icon--just like Carbon or Cocoa apps--with nothing to download, install, or configure.

very few people will ever use X11 on a Mac.

We agree on that point. And that makes the Mac a minor player when it comes to the UNIX workstation market. Apple should stop marketing it as such until they actually support a standard suite of workstation software out of the box.

Re:X11 is not really supported

[pudge]

Too bad it doesn't run most of the scienctific and engineering software people use. Heck, it doesn't even run Matlab--for that you need X11.

Yes, of course you need X11 for certain things. No kidding.

Yup, a gearhead like you would snicker. Most people find the idea of downloading a 53Mbyte package, installing it, setting it up to auto-start at startup, figuring out DISPLAY settings, and all that daunting.

There is no need to set DISPLAY settings, and there is no need for it to start automatically. And no one who can install MATLAB could possibly find installing XFree86 for Mac OS X to be difficult or "daunting." You are just making stuff up.

And when you are done, you end up with a flickering, sluggish, and bloated implementation of X11.

Like every other implementation of X11, you mean. So?

If Apple wants to make MacOSX an easy-to-use UNIX workstation alternative, they need to make X11 applications as easy to start up as double-clicking on an icon--just like Carbon or Cocoa apps--with nothing to download, install, or configure.

This is just stupid. It is as easy to download and install as any other software program. It's easier to configure than X11 on any other platform, except for machines that come with it already configured, which isn't the case with most Linux and BSD machines, as already shown. And anyone can make an X11 app that will just start on double-clicking its icon. It's not difficult.

And that makes the Mac a minor player when it comes to the UNIX workstation market. Apple should stop marketing it as such until they actually support a standard suite of workstation software out of the box.

They do. You making stuff up about it not won't change anything.

Re:X11 is not really supported

[g4dget]

Like every other implementation of X11, you mean. So?

X11 implementations exist that run in less than 1Mbyte of RAM. Applications for X11 run on 16bit embedded systems and can be implemented in binaries a few kilobytes large.

Look at the processes on your Mac to see how huge even the simplest applications are. Terminal on X11 uses 1/6th the memory and is 80 times faster at displaying text than Terminal.app on my Mac (1GHz Athlon vs. 600MHz PPC), and that's true for many other applications as well.

There is no need to set DISPLAY settings, and there is no need for it to start automatically.

When a user installs X11, there are no links to X11 applications anywhere to be found in the Finder. When they manage to find the "xterm" executable (or almost any other X11 executable), it doesn't run when they double click on it. If they switch to the shell and try to run it from the command line, it won't run either because they need to set a DISPLAY environment variable. Maybe they figure out how to install OroborusX, but that's a limited set of applications, not usually what the user wants to run.

This is not a "well supported" X11 installation, and the user experience is much worse than on a UNIX workstation or preconfigured Linux machine. Apple needs to improve this.

Re:X11 is not really supported

[pudge]

X11 implementations exist that run in less than 1Mbyte of RAM. Applications for X11 run on 16bit embedded systems and can be implemented in binaries a few kilobytes large.

Yes, I meant PC-based systems.

Look at the processes on your Mac to see how huge even the simplest applications are. Terminal on X11 uses 1/6th the memory and is 80 times faster at displaying text than Terminal.app on my Mac (1GHz Athlon vs. 600MHz PPC), and that's true for many other applications as well.

Um ... what's that got to do with anything? You said the X11 implementation on Mac OS X stinks, and then you compare X11 on an Athlon to non-X11 on a Mac, neither of which has anything to do with X11 on a Mac.

When a user installs X11, there are no links to X11 applications anywhere to be found in the Finder.

When a user runs X11, there are links to X11 applications right in front of them, in the menu.

When they manage to find the "xterm" executable (or almost any other X11 executable), it doesn't run when they double click on it.

Neither does this happen in many other X11 environments.

If they switch to the shell and try to run it from the command line, it won't run either because they need to set a DISPLAY environment variable.

Not if they execute it within xterm, which opens automatically on running XDarwin.

Maybe they figure out how to install OroborusX, but that's a limited set of applications, not usually what the user wants to run.

So, as with every other OS, they type its name on the command line if they don't see it there. Remember, we are talking about smart people here, the ones you say are smart enough to use MATLAB, but somehow not smart enough to type the name of a program to run.

The main point here is that a. anyone who wants X11 can figure it out easily, and b. almost no one wants X11. If Apple bundled it, that wouldn't change. People don't want X11 because X11 sucks. People only use it when they have to use it, to get at specialized software. People would rather use an inferior IRC client in Cocoa or Carbon than a better one in X11, even if X11 is installed and configured, because X11 inherently sucks a lot more.

Re:X11 is not really supported

[g4dget]

The main point here is that a. anyone who wants X11 can figure it out easily, and b. almost no one wants X11. If Apple bundled it, that wouldn't change. People don't want X11 because X11 sucks. People only use it when they have to use it, to get at specialized software. People would rather use an inferior IRC client in Cocoa or Carbon than a better one in X11, even if X11 is installed and configured, because X11 inherently sucks a lot more.

Then Apple's smart engineers can figure out how to make it suck less and add value to it; XFree86 on OS X doesn't cut it. Given that there are a huge number of X11 users out there (almost certainly more than OS X users), it's a market opportunity that Apple would be foolish to miss.

Re:X11 is not really supported

[pudge]

Then Apple's smart engineers can figure out how to make it suck less and add value to it; XFree86 on OS X doesn't cut it.

Well, let's see. I've shown that it is easier to install and configure than on any other OS (except for the very few PCs that actually come with it preinstalled). You've shown that you can't double-click on things, and that if you want to use Terminal.app, then you need to set an environment variable first.

And somehow this comes does to "it sucks". Riiiiiiight.

it's a market opportunity that Apple would be foolish to miss.

There is no one who wouldn't buy a Mac merely because they needed to install X11 separately. These people do not exist. Anyone who says they are such people clearly have other issues.

Re:X11 is not really supported

[tokki]

I guess that's why everyone finds Linux GUI's so very easy, and use them instead of Apple or Microsoft.

Aple in the news.

[Anonymous Coward]

Apple is making lots on news lately. I love it.

well... OSX 11.0 i'd assume.

[Anonymous Coward]

It's OSX 10.x. So it's resonable to assume after version 10 will be version 11. Therefor OSX 11.0, 11.1 etc.

Panic logging

[po8]

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.

Huh? Except for writing into RAM instead of NVRAM (which is almost always sufficient), versions of UNIX and other OSes in the 1980s always did this. This is essentially what dmesg(8) is for.

Please stop making me feel old. Kids these days... :-)

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!

kernel panic info

[surfsalot]

"including the idea of storing kernel panic info in NVRAM and writing it to a logfile on reboot." Not to be a bring down to the party (I own only apple and sun machines) but just to be fair, sun has had this since solaris 2.6 (possibly earlier)...

Re:kernel panic info

[Anonymous Coward]

actually, solaris writes it to the swap device and will write out a core file on reboot if savecore is enabled and there is sufficient room on the file system

Re:kernel panic info

[2nd Post!]

Now you can say Apple has had this feature since OS X 1.2 errr 10.2!

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.

File cannot be found

[Version6]

At about 11:42 PDT, while poking around in the Tech Note, I suddenly started getting an error from Mozilla:

"The file /technotes/tn2002/tn2053.html" cannot be found. Please check the location and try again.

I went to the Apple developer site and searched around, but I was unable to find tn2053 (I did run across tn2052, so I might have been close).

Is it just me, or did something suddenly change?

Re:File cannot be found

[Maserati]

It's back. I'm not sure if anything changed in the TN, but it's there again.

Re:File cannot be found

[Van Halen]

Was it a Mozilla dialog box or a server error page? I had a similar problem the other week accessing a website I was working on: Mozilla kept popping up an error dialog saying it couldn't find the file. Seems it had started looking for a local file rather than the web url, no matter how hard I tried to convince it that the address was really a http://. Restarted Mozilla and all was fine. Weird bug.

Change that silly grey Apple

[Anonymous Coward]

OFF Topic and COOL, Mod this up +5 'cause it's cool.

I made the grey apple that appears on startup into a nice blue gradiented, drop shadowed Gamecube Logo. Now my Mac starts with the game cube logo. The image is 128 by 128 and is in raw format with a color table, photoshop handled it after a lil hackery. A simple change in the BootX file and bang.

If you're interested in creating your own boot logo and need more help write to me at eddie@actaeon.nospam.net , but without the .nospam Cheers, Eddie

Re:Change that silly grey Apple

[arson1]

r just go here for complete instructions http://www.ryandesign.com/jagboot/

And Ruby too...

[Anonymous Coward]

The Ruby scripting language is now installed with Mac OS X. (r. 2809964).

NVRAM

[Anonymous Coward]

Well, then someone could write a virus which lives in the NVRAM. Nice.

Re:NVRAM

[anarkhos]

Except you can't write to NVRAM without root in the first place.

You moron...

Why not Python 2.2?

[Nice2Cats]

Why Python 2.1 and not 2.2, which has Iterators and a whole lot of other new power toys? If I remember correctly, my SuSE 8.0 came with 2.2 (not 2.2.1) months ago...

And Tru64 Unix ...

[Macka]

.. compresses and writes the contents of memory out to the primary dump device. When the system reboots, it looks for a dump header in swap and if it finds one, writes it out to a crash dump directory along with a copy of the current kernel. Lastly, it runs 'crashdc' and performs an preliminary analysis and report on the contents of the cpu stacks, etc.

From a trouble shooting point of view, it's very useful and time saving.

Re:And Tru64 Unix ...

[Macka]

sorry .. I should have been clearer. Primary dump = primary swap (where you may have multiple swap devices).

Re:And Tru64 Unix ...

[Anonymous Coward]

HP-UX does that too. And there is a reason that only those crappy OS'es do it that way:

Oh f*ck, there is a bug in the disk driver, we just copied a bunch of zeroes over the start block of the swap/dump device. Oh well, better to a crash dump then... Whoops, no more superblock or inode table.

Win over Windows users

[OrangeSpyderMan]

In a bid to win over MS Windows users who up until now have been worried about loosing the registry bloat of their OS, Apple has invented an equivalent that gradually fills up with cruft and needs purging once in a while. Hehe :-D

Re:Win over Windows users

[afidel]

Oh if only the registry were that easy to fix......

Re:Win over Windows users

[Lazaru5]

While I appreciate the humor in your observation of that irony, this only refers to developers.

CUPS

[Morky]

It's nice on a Window's-based LAN, too. I can finally print from OS X to a PCL printer attached to a Windows machine's parallel port.

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

Re:[OT] IPSec and OSX

[Junta]

BTW, after further research, I found that the instructions at http://www.kame.net/ to be helpful, since IPSEC under 10.2 is kame (racoon and all)

Carbon vs Cocoa

[Aapje]

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.

This is total nonsense. Carbon might not be as easy as Cocoa, but you can do just about everything with it that you can also do in Cocoa (and vice versa). In fact, Cocoa and Carbon are more and more achieving parity. You can choose the solution that you like best and nobody will know*.

*Except that one of the two results in apps that start faster and can run on an old OS that still has a big following. ;)

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

Why? Carbon is a total rewrite, I doubt that it's not portable (why wouldn't it be?). Again, uninformed FUD. Especially if you know that MacOS 7 was ported to x86 by Apple (the Star Trek project). Do you think a port would be impossible for the cleaned up version of (essentially) the same API?

Re:Carbon vs Cocoa

[andrewski]

Except that one of the two results in apps that start faster and can run on an old OS that still has a big following.

Yeah, there are still a lot of people who use Nextstep / Openstep. It would be trivial to port most Cocoa apps to those old OS's.

As a side note, have you ever seen how fucking slow Explorer starts? Or Office X? Then launch a Cocoa app and see the difference. Especially under 10.2!

Anyway, every time I see the little watch, or the old monochrome spinny ball, I know I'm looking at old technology. The star trek project was anything but comprehensive or complete. Besides, that's a different animal, as the Mac ran on 68xxx hardware then.

I'm sorry if you feel that Carbon is as good as Cocoa, but you are just plain wrong. Apple has never said that Carbon is a rewrite. It's likely just the old Mac toolkit with most of the cruft removed. I am actually quite informed on this issue. Look into the Carbon documentation, though, and you'll still find much old cruft.

I have developed for the old Mac OS and refuse to touch Carbon. What a fucking mess! Cocoa has been beautiful since the 80's, and IMHO there isn't a development environment that can even come close to matching it.

Re:Carbon vs Cocoa

[wchin]

You can choose the solution that you like best and nobody will know*.

*Except that one of the two results in apps that start faster and can run on an old OS that still has a big following. ;)

However, when Carbon apps are busy, the user can't move any of it's windows. Very, very frustrating. Also, Carbon apps not written specifically for Mac OS X have definite disadvantages and are pretty easy to spot. Just look for the most ugly and non-conforming applications except for the pure Java ones.

Plus, it's usually the Carbon apps that don't properly leverage the operating system or contain lots of cruft like 31 character file name limits or have constantly running loops that hog CPU time and consume battery power, even when they're supposed to be totally idle. It's usually the Carbon developers that can't quite "get" daemons and proper modern application architecture. It's a good thing for them that there's a huge installed base out there that are almost as backwards thinking as they are to keep buying their products. A lot of the rest have moved onto Windows or something else.

Re:Carbon vs Cocoa

[Aapje]

Yeah, there are still a lot of people who use Nextstep / Openstep.

Just like 'a lot' of people still use an Amiga or OS/2? I think that my definition of 'a lot' is a bit different from yours.

It would be trivial to port most Cocoa apps to those old OS's.

Well duh, those are the predecessors to OS X. Of course, I haven't seen any program which was back-ported, because few people use these OS's. Everyone I know who used it moved to OS X or Windows (five people, probably a good part of the NeXT users in the Netherlands ;) ).

As a side note, have you ever seen how fucking slow Explorer starts? Or Office X? Then launch a Cocoa app and see the difference. Especially under 10.2!

Those are two badly programmed apps. An empty Carbon app will start up faster than an empty Cocoa app (assuming the Carbon app uses PEF).

The star trek project was anything but comprehensive or complete. Besides, that's a different animal, as the Mac ran on 68xxx hardware then.

It was a proof of concept. Apple decided not to proceed because of strategic concerns, not because of technical problems.

I'm sorry if you feel that Carbon is as good as Cocoa, but you are just plain wrong.

I can't remember saying that. I'm saying that Carbon has advantages and disadvantages compared to Cocoa. Neither is perfect for everything, which is why Carbon shouldn't be and won't be removed from OS X.

Apple has never said that Carbon is a rewrite. It's likely just the old Mac toolkit with most of the cruft removed.

It's a rewrite in the sense that Apple has examined all the old stuff, scrapped obsolete API's, retooled many others, added quite a bit of new stuff and retested the result in a preemptive PPC-only environment. It's not a complete rewrite, but a rewrite it is.

I have developed for the old Mac OS and refuse to touch Carbon.

I guess that your company doesn't have a big application out for OS 9 (or customers to support on that OS). I guess that you don't have engineers on hand who only have experience with the old MacOS. If you had to choose before Codewarrior supported Cocoa, a move to Cocoa would have meant changing your IDE (and some of your custom little utilities), that is risky as well. You might have a plug-in system in your application. Moving to Cocoa would hurt the plug-in developers greatly. If you want to have a single codebase for multiple platforms, Carbon might be the best decision. I don't know a single cross-platform Cocoa app. A Carbon app can certainly be crossplatform with manageable costs. This hasn't been proven for Cocoa.

Cocoa has been beautiful since the 80's, and IMHO there isn't a development environment that can even come close to matching it.

Yep, but development environments don't get chosen just for being beautiful. In real life there are many other considerations. You might even end up using VB for something and NOT be wrong. It all depends on the circumstances.

Re:Carbon vs Cocoa

[Aapje]

However, when Carbon apps are busy, the user can't move any of it's windows. Very, very frustrating. Also, Carbon apps not written specifically for Mac OS X have definite disadvantages and are pretty easy to spot. Just look for the most ugly and non-conforming applications except for the pure Java ones.

It doesn't have to be that way. A properly threaded, Carbon evented program will run perfectly. Of course there will be Carbon programmers who still have to learn to conform, but that goes for some NeXT-programmers as well.

Plus, it's usually the Carbon apps that don't properly leverage the operating system or contain lots of cruft like 31 character file name limits or have constantly running loops that hog CPU time and consume battery power, even when they're supposed to be totally idle. It's usually the Carbon developers that can't quite "get" daemons and proper modern application architecture.

It seems to me that you don't have a problem with Carbon, but with its programmers. They are rapidly learning, did you seriously expect them to immediatly pick up all this new technology overnight? They were happy to run on OS X for the first release. They are now working on better compliance since their customers are asking for it. Is that not the way it should be?

It's a good thing for them that there's a huge installed base out there that are almost as backwards thinking as they are to keep buying their products. A lot of the rest have moved onto Windows or something else.

Users don't care whether you are using Cocoa or Carbon, they care about good apps. If you think you can provide a better experience for users with a certain API, please do. But don't be an idiot by blaming users for having rational desires like:
- I don't want to throw away my experience in using this app unless there is a good reason.
- I want to be able to use my old files.
- I don't want to spend money if I can avoid it.
- I need to cooperate with others, either by using the same apps or having perfect import/export.
- I want to use a/the GUI that allows me to work easily and fast.
- MacOS X should be able to do just about everything that OS 9 can do.

Disregarding these things is not forward-thinking. Deriding users for having certain preferences isn't smart, reasonable or respectful. But hey, why be nice to the people that pay your salary?

Matlab is using OroborOSX

[bill_mcgonigle]

a fabulous semi-aqua carbon manager written in Carbon. check it out.

Re:X11 is not really supported (OT whine)

[good soldier svejk]

Isn't this what I said in my original post? I even included a link (albeit OS X GNU, not sourceforge) to the binary installer. I am starting to feel unheard.

When the new Windows SP EULAs came out I posted a response about how it would be a HIPPA violation for me to accept it. Nobody replied and I received no moderation. Last week, my point shows up as a headline here and all of the sudden everybody has an insight. Slashdot is just a boys club isn't it?

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.

Re:the _best_ feature: ktrace works!

[Anonymous Coward]

Thank God! All the bug reports I submitted during the MOSX beta period ended with, "Of course, if you compiled the kernel with tracing enabled, I could provide more detailed information (hint, hint)."

Unsurpringly, no response from them. *shrug*

Re:X11 is not really supported (OT whine)

[Draoi]

g4dget wasn't really listening to you. They saw your mention of fink and ran with it.

You also said that you dl'd the xterm sources and re-built it. Well and good, but there's been a package for this since round about the time Jag was released. I pointed out that there's no need for a build - just grab the xterm updater and go.

I'd say your comments were largely right-on & g4dget needs to wake up & read the responses ...

Slashdot is just a boys club isn't it?

There Is No Cabal. (They made me say that! ;-) )

Re:X11 is not really supported (OT whine)

[g4dget]

I don't see why this is so hard to understand: "fink" and setting up XFree86 on OSX is beyond the capabilities of most Macintosh users. Trust me. I have been there, trying to help people do it.

Furthermore, if there is no binary package for something in fink, fink has to recompile the sources, and that does require downloading and installing the development environment.

You both display the kind of geekiness in your attitudes that Macintosh is supposed to protect users from. Come on, the main reason to use a Macintosh over some other UNIX workstation is that it "just works". Anything that requires downloading and fiddling around dozens of megabytes of stuff and going into the command line doesn't "just work".

Re:X11 is not really supported (OT whine)

[Draoi]

I agree with your fink comment. Fink is great but it's not for the average Mac user. However, on setting up X on Jaguar, I disagree. Download two pkgs and double-click 'em - how easy can it get? The pkg even puts an alias with a big 'X' in the dock. You click on it and X starts up rootless. It's a dream ...

You don't *need* fink to install X! Want me to say it again?

X just works on Jaguar. More and more X11 apps are being packaged for that 1-click(tm) response that Mac users are so accustomed to.

Sure, you and I use fink - but then again I suspect you and I don't run the average X11 apps, either. The GIMP is now available as a .pkg download for the Mac. Download & click, buy the CD and click, whichever. It JUST WORKS .....

I don't know where you're getting your "fiddling around dozens of megabytes of stuff and going into the command line", 'coz it doesn't apply in this case.

[Full disclosure: I work for Apple as a developer but right now, I'm speaking for myself. Just before someone else brings this up]

Re:X11 is not really supported (OT whine)

[good soldier svejk]

I apologize. My comment wasn't really aimed at you. I was merely venting my frustration at the oppressive slashdot establishment. Your post added to the discourse. I didn't know there was an updated xterm binary package much less a GIMP one. I'll need to check up on such things more often.

I think it was really the HIPAA thing that was bugging me. Slashdot should tell me it loves me more often.

Re:X11 is not really supported (OT whine)

[g4dget]

I don't know where you're getting your "fiddling around dozens of megabytes of stuff and going into the command line", 'coz it doesn't apply in this case.

I have had to help too many people to get a working X11 environment on OSX: it doesn't "just work". Maybe the server starts up with a couple of clicks, if you are lucky, but there is more to do. A well-integrated version of X11 would allow people to just double click on any X11 application and run it just like a Carbon application on an out-of-the-box Mac, with standard OSX window management, transparency support, and hardware acceleration.

However, on setting up X on Jaguar, I disagree. Download two pkgs and double-click 'em - how easy can it get?

It can get as easy as not having to think about it at every upgrade, not having to download 53Mbytes, like I don't have to on other UNIX workstations. It can get as easy as making the differences between X11 and Cocoa as small as those between Carbon and Cocoa from the user's point of view.

If Apple wants to be in the scientific and engineering workstation market, they have to make it as easy as that, because otherwise OSX is a lot more hassle than a UNIX workstation.

Mac IIfx vs. PowerBook

[capmilk]

Let's see... the high performance SCSI disk (for the time) in your IIfx was how fast? The laptop ATA drive in your G4 PowerBook is how fast? Hmmm... not much difference is there?

The IIfx is relatively slow whereas the PowerBook is relatively fast.
Still, it kinda makes you wonder that starting Terminal.app still takes more than a second until you can see your prompt, doesn't it?

Re:X11 is not really supported (OT whine)

[drsmithy]

I don't see why this is so hard to understand: "fink" and setting up XFree86 on OSX is beyond the capabilities of most Macintosh users. Trust me. I have been there, trying to help people do it.

Installing XFree on OS X is about as hard as grabbing the installer package and double clicking it. That's why it's "so hard to understand".