Slashdot Mirror


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

70 of 153 comments (clear)

  1. Check out the BSD section by Demona · · Score: 4, Informative

    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)

    --
    Fuck Slashdot
    1. Re:Check out the BSD section by opk · · Score: 2, Interesting

      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.

    2. Re:Check out the BSD section by Macka · · Score: 2


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

    3. Re:Check out the BSD section by Macka · · Score: 2



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

  2. Re:some thoughts by Dephex+Twin · · Score: 4, Informative
    Are cursors that big really that necessary?

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

    If you want to make an apple pie from scratch, you must first create the universe. -- Carl Sagan
  3. Re:some thoughts by Yarn · · Score: 2, Insightful

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

    --
    -Yarn - Rio Karma: Excellent
  4. Re:some thoughts by Wiwi+Jumbo · · Score: 3, Interesting

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

    --
    Wiwi
    "I trust in my abilities,
    but I want more then they offer"
  5. including the idea of storing kernel panic info in by kangolo · · Score: 3, Interesting

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

  6. Horay. Finally automake by Billly+Gates · · Score: 3, Insightful

    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!

    1. Re:Horay. Finally automake by Lazaru5 · · Score: 2

      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.

      --

      --
      My comments and opinions completely reflect those of anyone and anything I am remotely associated with.
  7. Re:including the idea of storing kernel panic info by Chanc_Gorkon · · Score: 2

    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.

    --

    Gorkman

  8. Other gems that are included by wfolta · · Score: 3, Insightful
    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?
  9. Python in X by Tar-Palantir · · Score: 3, Informative

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

  10. Math libraries included, too... by wfolta · · Score: 5, Interesting
    • 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.
  11. Thought this was interesting... by VValdo · · Score: 3, Interesting

    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

    --
    -------------------
    This is my SIG. There are many like it, but this one is mine.
    1. Re:Thought this was interesting... by Phroggy · · Score: 2

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

      (kidding!)

      --
      $x='S24;r)>63/* h@<5+oZ)32"5cz';$me='phroggy'x$];
      $x=~y+ -xz+\0-Tx+;print$_^chop$me for split'',$x;
  12. Re:some thoughts by lemkebeth · · Score: 2, Informative

    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.

  13. Re:including the idea of storing kernel panic info by g4dget · · Score: 2

    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.

  14. X11 is not really supported by g4dget · · Score: 5, Insightful
    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.

    1. Re:X11 is not really supported by andrewski · · Score: 5, Insightful

      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?

    2. Re:X11 is not really supported by bnenning · · Score: 3, Informative
      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.

      --
      How to solve most of our problems: 1.Lots of nuclear plants. 2.Cure aging.
    3. Re:X11 is not really supported by g4dget · · Score: 4, Interesting
      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.

    4. Re:X11 is not really supported by g4dget · · Score: 2
      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.

    5. Re:X11 is not really supported by am+2k · · Score: 3, Insightful
      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...?

    6. Re:X11 is not really supported by Draoi · · Score: 4, Informative
      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??

      --
      Alison

      "It is a miracle that curiosity survives formal education." - Albert Einstein

    7. Re:X11 is not really supported by pudge · · Score: 2
      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.
    8. Re:X11 is not really supported by Lars+T. · · Score: 2
      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?

      --

      Lars T.

      To the guy who modded me down from perfect to terrible Karma - Apple haters still suck

    9. Re:X11 is not really supported by g4dget · · Score: 2
      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.

    10. Re:X11 is not really supported by kalidasa · · Score: 2

      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.

    11. Re:X11 is not really supported by g4dget · · Score: 2
      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.

    12. Re:X11 is not really supported by ikekrull · · Score: 2

      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.

      --
      I gots ta ding a ding dang my dang a long ling long
    13. Re:X11 is not really supported by g4dget · · Score: 2
      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.

    14. Re:X11 is not really supported by g4dget · · Score: 2
      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.

    15. Re:X11 is not really supported by pudge · · Score: 2
      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.

    16. Re:X11 is not really supported by g4dget · · Score: 2
      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.

    17. Re:X11 is not really supported by pudge · · Score: 2

      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.

    18. Re:X11 is not really supported by g4dget · · Score: 2
      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.

    19. Re:X11 is not really supported by pudge · · Score: 2

      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.

    20. Re:X11 is not really supported by g4dget · · Score: 2
      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.

    21. Re:X11 is not really supported by pudge · · Score: 2

      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.

  15. Re:some thoughts by Maserati · · Score: 4, Informative

    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.

    --
    Veteran, Bermuda Triangle Expeditionary Force, 1992-1951
  16. Re:some thoughts by be-fan · · Score: 3, Informative

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

    --
    A deep unwavering belief is a sure sign you're missing something...
  17. Re:some thoughts by ealar+dlanvuli · · Score: 2

    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)

    --
    I live in a giant bucket.
  18. Panic logging by po8 · · Score: 2

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

    1. Re:Panic logging by Macka · · Score: 3, Insightful



      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!

  19. Hoorah for CUPS! by tm2b · · Score: 4, Informative

    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.

    --
    "It is our blasphemy which has made us great, and will sustain us, and which the gods secretly admire in us." - Zelazny
  20. Re:some thoughts by Saint+Fnordius · · Score: 2

    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.

  21. Re:some thoughts by Yarn · · Score: 2

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

    --
    -Yarn - Rio Karma: Excellent
  22. And Tru64 Unix ... by Macka · · Score: 2

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

    1. Re:And Tru64 Unix ... by Macka · · Score: 2


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

  23. Win over Windows users by OrangeSpyderMan · · Score: 2, Interesting

    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

    --
    Try NetBSD... safe,straightforward,useful.
  24. Re:Change that silly grey Apple by arson1 · · Score: 2

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

    --


    --
    Don't sweat the petty things, and don't pet the sweaty things.
  25. [OT] IPSec and OSX by Junta · · Score: 3, Interesting

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

    --
    XML is like violence. If it doesn't solve the problem, use more.
    1. Re:[OT] IPSec and OSX by Junta · · Score: 2

      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)

      --
      XML is like violence. If it doesn't solve the problem, use more.
  26. Carbon vs Cocoa by Aapje · · Score: 2

    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?

    --

    The Drowned and the Saved - Primo Levi
    1. Re:Carbon vs Cocoa by Aapje · · Score: 2

      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.

      --

      The Drowned and the Saved - Primo Levi
    2. Re:Carbon vs Cocoa by Aapje · · Score: 2

      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?

      --

      The Drowned and the Saved - Primo Levi
  27. Re:some thoughts by Junks+Jerzey · · Score: 2

    Are cursors that big really that necessary?

    When screen resolution is high enough, yes.

  28. Matlab is using OroborOSX by bill_mcgonigle · · Score: 2

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

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  29. the _best_ feature: ktrace works! by GrumpyOldMan · · Score: 3, Informative

    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.

  30. Re:X11 is not really supported (OT whine) by Draoi · · Score: 2
    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! ;-) )

    --
    Alison

    "It is a miracle that curiosity survives formal education." - Albert Einstein

  31. Re:some thoughts by Lars+T. · · Score: 2

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

    --

    Lars T.

    To the guy who modded me down from perfect to terrible Karma - Apple haters still suck

  32. Re:some thoughts by Lars+T. · · Score: 2

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

    --

    Lars T.

    To the guy who modded me down from perfect to terrible Karma - Apple haters still suck

  33. Re:some thoughts by be-fan · · Score: 2

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

    --
    A deep unwavering belief is a sure sign you're missing something...
  34. Re:some thoughts by SlamMan · · Score: 2

    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.

    --
    Mod point free since 2001
  35. Re:X11 is not really supported (OT whine) by g4dget · · Score: 2
    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".

  36. Re:some thoughts by kwerle · · Score: 2

    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.

  37. Re:X11 is not really supported (OT whine) by Draoi · · Score: 2
    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]

    --
    Alison

    "It is a miracle that curiosity survives formal education." - Albert Einstein

  38. Re:X11 is not really supported (OT whine) by g4dget · · Score: 2
    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.

  39. Re:kernel panic info by 2nd+Post! · · Score: 2

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