Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
OS X Businesses Operating Systems Apple

Mac OS X 10.2 Technote Released 153

Posted by chrisd from the they-used-to-be-fine-automobiles dept.
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."
This discussion has been archived. No new comments can be posted.

Mac OS X 10.2 Technote Released More

Mac OS X 10.2 Technote Released

Comments Filter:

  • 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 (Score:4, Informative)

      by Dephex Twin ( 416238 ) on Tuesday September 03, 2002 @04:57PM (#4191683) Homepage
      Are cursors that big really that necessary?

      Beneficiaries that immediately spring to mind are children and vision-impaired.
      • And people with a higher resolution display. Maybe the next Cinema Display?

    • Re:some thoughts (Score:2, Insightful)

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

      • Re:some thoughts (Score:3, Interesting)

        by Wiwi Jumbo ( 105640 )
        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... :)
        • I suggest you email that to Apple, surely they have a "suggestions box" email address?

        • Re:some thoughts (Score:3, Informative)

          by be-fan ( 61476 )
          But cursors in current machines are hardware drawn (quite an good performance improvement actually) and current hardware doesn't do vector cursors.
          • 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)
            • Sun's old OpenView used to have all its cursors as fonts. Great fun changing it. Well, a little fun at least.
            • And the scaling algorithm is already there for icons. And I'm not even going to mention Quartz Extreme.
            • 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 :)
    • ... 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:some thoughts (Score:4, Informative)

      by Maserati ( 8679 ) on Tuesday September 03, 2002 @09:43PM (#4193119) Homepage Journal

      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.

    • 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.
    • Are cursors that big really that necessary?

      When screen resolution is high enough, yes.
    • 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.
    • 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.

  • Check out the BSD section (Score:4, Informative)

    by Demona ( 7994 ) on Tuesday September 03, 2002 @04:52PM (#4191657) Homepage
    Linux users should appreciate some of the nice changes in the BSD section [apple.com]. 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)
    • 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. :-)

    • 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?

      • Math libraries included, too... (Score:5, Interesting)

        by wfolta ( 603698 ) on Tuesday September 03, 2002 @08:25PM (#4192736)
        • 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:Check out the BSD section (Score:1, Interesting)

      by 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

    • Hoorah for CUPS! (Score:4, Informative)

      by tm2b ( 42473 ) on Tuesday September 03, 2002 @11:57PM (#4193529) Journal
      My favorite change: the printing system was been replaced with CUPS [cups.org], allowing Mac OS X users with printers from companies who enjoy screwing Mac users (*cough* Epson *cough*) to use Gimp-Print drivers [sourceforge.net]. Hoorah, open source support!

      How to install the Gimp-Print drivers is detailed here [allosx.com]. It's trivial.
    • 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.

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

  • 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 (Score:3, Interesting)

    by kangolo ( 95008 ) on Tuesday September 03, 2002 @06:58PM (#4192304)
    > 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.
    • 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.
    • IRIX as well, at least for the past 10 years.
    • 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.
    • .. 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.

  • Horay. Finally automake (Score:3, Insightful)

    by Billly Gates ( 198444 ) on Tuesday September 03, 2002 @07:07PM (#4192349) Journal
    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!

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

    • X11 is not really supported (Score:5, Insightful)

      by g4dget ( 579145 ) on Tuesday September 03, 2002 @09:06PM (#4192959)
      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.

      • 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 (Score:5, Insightful)

        by andrewski ( 113600 ) on Tuesday September 03, 2002 @09:34PM (#4193084) Homepage
        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?
        • 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.
        • 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.
          • 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.
          • 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.

        • 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 (Score:1, Interesting)

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

          • 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 [mozdev.org] 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.

            • 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?

          • 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 (Score:4, Interesting)

          by g4dget ( 579145 ) on Wednesday September 04, 2002 @12:39AM (#4193633)
          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.

          • 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...?

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

        • 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?

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

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

      • 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 [sourceforge.net] aside, you can get an OS X binary package from the OS X Gnu [osxgnu.org] guys.
        • 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 (Score:4, Informative)

            by Draoi ( 99421 ) <<moc.cam> <ta> <thcoiard>> on Wednesday September 04, 2002 @04:44AM (#4194089)
            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 [sourceforge.net] 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 [ic.ac.uk] 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??

      • 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 [sourceforge.net]. 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.
        • 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.

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

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

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

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

                    • 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.
      • a fabulous semi-aqua carbon manager written in Carbon. check it out [sourceforge.net].
    • 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.

  • Python in X (Score:3, Informative)

    by Tar-Palantir ( 590548 ) on Tuesday September 03, 2002 @08:23PM (#4192729)
    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).

    • And Ruby too... (Score:1, Informative)

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

  • Thought this was interesting... (Score:3, Interesting)

    by VValdo ( 10446 ) on Tuesday September 03, 2002 @08:25PM (#4192739)
    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

  • Another reason to love my new iBook (Score:1, Interesting)

    by 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!

  • 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 (Score:3, Insightful)

      by Macka ( 9388 )


      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!

  • "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)...
  • 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?

  • [OT] IPSec and OSX (Score:3, Interesting)

    by Junta ( 36770 ) on Wednesday September 04, 2002 @08:41AM (#4194729)
    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! (Score:3, Informative)

    by GrumpyOldMan ( 140072 ) on Wednesday September 04, 2002 @10:15AM (#4195196)
    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.

Slashdot Top Deals

Be sociable. Speak to the person next to you in the unemployment line tomorrow.

Close