Please welcome Brett Halle, Director of Core OS Engineering. Good afternoon. So we're going to spend a little bit of time today and talk about Darwin. Darwin is kind of the bottom layer of Mac OS X, and if you're interested in focusing a little bit on kind of the plumbing and that kind of stuff, this is the right place to be.

I think this picture actually really misrepresents the importance of Darwin. So let's see. Ah, that's better. I think that's a little bit better. Like I said, Darwin really is the bottom layer of Mac OS X. It's the foundation upon which the system is built. We're going to spend a little bit of time in this session and give you a really brief overview of what the technologies are, although probably most of you know what those things are. But we want to spend a little bit more time and tell you a bit about what we've been doing as far as Jaguar is concerned and the kinds of services and facilities that you want to be able to take advantage of.

Like I said, you really need to think of the Core OS and Darwin as really the foundation of the building, of all the rest of Mac OS X sits on top of it. It supports all the frameworks and all the other stuff that make up the system, and a lot of our job is to really be as invisible as possible to everybody because we are that kind of plumbing in the walls and the stuff on the bottom. For Jaguar, we've been doing a bit of digging of some things up putting in some new plumbing and stuff. We'll talk a little bit about some of the new plumbing work we've been doing. Hopefully you'll find this to be pretty exciting. First, let's start with Mach. Mach is the actual base, if you will, of Mac OS X. It's responsible for managing all the processor resources and memory resources of the system. Architecturally you might consider Mach as a microkernel, but the way we've built it into the system is very highly integrated into the rest of the kernel environment. But its job really is to be able to be kind of a policy-neutral layer of the system to manage the processor and memory resources. What's really important to note about Mach and why it is important to the people in this room is that everything else is built on top of Mach. All the process models that exist in the system are fundamentally built on top of mocks, mocks, concepts of tasks and threads. And that all memory management in the system is built on top of Mach. So all the kind of backing store management, the actual handling of virtual memory and paging is all ultimately handled by Mach. And all the communication between processes and between the user land applications in the kernel are primarily built on top of Mach primitives. So it's important to realize that these are really pretty important building blocks, and you'll see bits and pieces of Mach kind of expose itself through other services that are all the way up into things like CF network and above. So it's important to realize that this is a key part of the system.

For Mach, on top of Mach or tightly integrated with Mach is the BSD kernel. This is really what provides the OS personality, if you will, for the system. This is where policy is actually brought into the picture. For us, this Mach kernel is based on the BSD 4.4 Lite, plus we've spent quite a bit of time integrating it with Mach and I/O Kit, our IOS system. It provides kind of a higher level view of the process model, handling things like signals and resource reaping and other things of that nature. It also introduces some of the mechanism for handling some of the system security by having a concept of users and being able to, through the file system and other parts of the system, kind of enforce various forms of ownership and permissions. And as I mentioned, it really is responsible for kind of providing real DOS personality, if you will, of the system. You know, all of the high-level APIs for the OS are ultimately exported through the BSD APIs. those.

For Jaguar, we've done a number of interesting things down at the low-level kernel. One is we've done some interesting changing with how we handle panics. One of those things you should, of course, rarely ever see. But if you happen to be developing a drive or something like that, and something goes haywire, well, the system will panic. And you've probably seen with the existing 10.1 system that it splashes a whole bunch of stuff on the screen, at which point you have to sit there with a pencil and paper jot it all down because there's actually useful information in there. One of the things we've done with Jaguar is actually capture all the state of a panic. This information gets stored away and saved across the reboot of the system. The next time the system is booted, as long as it wasn't powered down, it will actually collect the panic state information, and this actually gets logged into the CrashCatcher application that's part of Mac OS X. At which point, then you can just cut and paste, which is certainly a lot more enjoyable. And hopefully, if you unfortunately find a bug of ours, you can just cut and paste that and send it off as a bug report. We've also done a bit of work in the kernel with processor scheduling improvements, particularly in multiple CPU environments. So that there's now the ability, as of today, the kernel is preemptible at multiple levels. And we've added additional capability in multiple CPU environments for there to be cross-processor preemption signaling to occur, as well as to start introducing some mechanisms for supporting processor affinity so that efficient action of executing thread doesn't end up getting moved from processor to processor and losing all the cache state. In the VM system, there's been some pretty exciting stuff as far as performance work is concerned.

in two primary things. One is what we call basically an adaptive application profile. And what ends up happening is when an application is launched on the system, the kernel actually pays attention to the VM activity during that particular process and effectively snapshots a profile of what occurred during the launch. The next time you launch that application, the kernel will actually take advantage of the fact that it knows and is able to effectively read ahead and do additional work to make the process of loading the application a lot faster. That's for the launching of an application. When actually running an application, there's what we call a working set cache, where basically an application's set of hot pages that are being used to execute the application are kept track of. And when you swap between, or context switch between multiple applications, The kernel will actually be very smart, again, about being able to try and keep the right things in memory so you're not spending a lot of time reading and writing process state. Of course, again, there's this caching process, or being able to do read-aheads and other types of collective I/O behavior. In the Pthreads environment, which affects certainly most of the threading models that most of the application environments use. We've added per-thread signal capability and added a number of additional Pthreads APIs to fill out the POSIX compatibility suite.

One thing to mention, if you happen to be someone who is developing in the kernel, we have a lot of things that we've learned in the process of shipping Mac OS X. And one area where we've spent quite a bit of effort is in designing I-O Kit, really making sure that there's an excellent, well-defined environment for developing drivers and other I-O related services and make sure that we can provide forward compatibility as we move the system forward. We'll talk more about I/O Kit in a few minutes. Elsewhere in the kernel, on the other hand, is a different story. We're constantly evolving the kernel, and a lot of work that we've done in Jaguar, in fact, has been a lot of upgrading and adding new plumbing in the kernel. And we've worked real hard to try and make sure that we keep everything within the kernel environment as compatible as possible, but we're going to change in the future. If you're going to develop in the kernel, make sure you develop, realize that you're kind of doing it at your own risk, The in kernel APIs and services that exist there will change, and we're going to be introducing new APIs over time that we'll be able to say you can have comfort with. But outside of the I/O Kit space, we really advise that you don't develop stuff within the kernel as you absolutely have to. If you do, come talk with us. Let's develop a relationship through developer relations to make sure that we can work with you from release to release.

If you're interested in developing in the kernel or getting more information on the kernel, there's a number of sessions you want to go to. The Darwin kernel session will go over both Mach and BSD pieces of the system in a lot more detail. There's also a session on Wednesday for managing kernel extensions. If you're doing I/O Kit work or other things within the kernel, it's really important you go to this session. There's a lot of useful information there. And if you're interested in more data on Pthreads and other threading, services that exist in Mac OS X, make sure you go to the writing threaded apps session on Thursday.

So moving on to I/O Kit. I/O Kit provides basically an object-oriented framework for making the process of writing device drivers as easy as possible and handling a lot of the common services and facilities that people who write device drivers need to deal with, things such as driver matching. When you plug in a device, making sure that the right driver actually ends up getting launched and loaded into the kernel. And handling things like power management and kernel-to-user communication between a device and some higher-level service that may need access to a given device. Within I/O Kit, there's a couple of different layers. Just to make sure the terms are clear to everybody, we've kind of broken this up because it's an object-oriented implementation that there's kind of this concept of families which provide the protocol kind of specifics. It allows you to make sure that the interfaces and services and things like that are appropriate to the kind of device, an audio device, for example, is going to behave and have different requirements than, you know, a disk device. And so the families provide the APIs and services that are kind of device-appropriate. The actual device drivers themselves end up talking to the family directly. That's kind of its interface to the world, and the family ends up generally talking to the rest of the system.

Within I/O Kit for Jaguar, there's a number of things that were done there, particularly the KEX system, which is the kernel extension environment. It's basically the set of facilities used to load things into the kernel to be able to handle linking all the bits and pieces together. When we shipped 10.1, we were focusing primarily on making sure the mechanism was there. There's a lot of work that's been done in Jaguar in terms of making additional services is available for you, the developer. So you want to go to the KEXT management session later in the week to learn a lot more about what those things are. But there's tools for debugging and tracking things and logging stuff that you'll find to be particularly helpful. As Steve mentioned this morning, as part of our tools work for Jaguar, we've upgraded to GCC3. Well, one thing you should probably note is GCC3's C++ ABI is actually different than what shipped in Mac OS X1. But the good news is that this is something that the I/O Kit team really considered from the get-go. And if you have existing drivers that ship today under X1, under the old 2.7, 297 compiler, that I/O Kit automatically handles the patch-up and keeps everything so that it's binary compatible, it's upward compatible. But it is important to note that if you write a device driver, on Jaguar later, that it will not be backwards compatible.

So that's something to factor into your development processes. One other area of enhancement within I/O Kit is the power management system. And a lot of tweaking there in terms of trying to get better battery life, to try and get better behavior and stuff in different power conditions. And in particular, being able to handle multiple power states, so being able to have different settings, if you will, for how the system behaves when it's plugged into the wall versus when it's just on battery. And support for UPSs. And one way I believe someone kind of described it to me is the UPS support is basically the ability to add the battery capability to your desktop. So the behavior of the power management system is very, very similar. Once the UPS goes into battery mode and actually notifies the system such, then it effectively behaves like a very large portable in terms of its power management behavior.

The HID manager, the human input device manager, has also been enhanced with I/O Kit. And in particular, again, a number of developer facilities, but trying to get more of the various devices integrated into one place so that the HID manager is now responsible for mice as HID devices as well as all the special game pads and all that kind of stuff that the HID manager is responsible for.

As you heard this morning, Steve mentioned, we have some directions. We'll hear more about Lent next week as far as servers are concerned, but there's a lot of work that I/O Kit's put into making sure that we can support headless booting. If you happen to be someone who makes graphics cards or things like that, one thing to factor in here is that it's really important to be able to have an environment like this, dynamic discovery of graphics devices.

something that the current NDRV models don't really support. That's one thing you basically go out and look for a display, and if it's not there, it stops. If you happen to be a graphics vendor, you really want to look at making sure that you look at using native graphics drivers on Mac OS X to be able to take full advantage of headless and dynamic display detection. And lastly, there's been quite a bit of work done in the PC card family. There was some stuff that came out as part of some of the software updates that you may have seen, additional PC card devices. With the Mac OS X and Jaguar, we also have a UI for now being able to make sure you can see what devices are there. If you want to remove one, you can effectively pull down a menu from the menu bar and, if you will, eject, although they don't physically eject at this point.

Number of sessions related to I/O you might want to go to. The managing kernel extensions is probably the single most important one. If you're developing in the kernel at all, developing device drivers, things, please go to this session. Lot of good stuff there. And then there's FireWire and USB sessions later in the week as well.

File systems. The file system portion of Mac OS X is a subsystem of the BSD kernel. It's basically based on a VFS, standard BSD VFS architecture, although we've enhanced it a bit to be able to support things like UTF-8 and other services that HFS+, for example, tends to export. We support a number of different file system types, HFS, HFS+, UFS, ISO, et WebDAV, which is a web-based file system architecture, UDF, Andrew File System, I believe somebody has ported out there. All the interfaces to the file system were designed to be able to support UTF-8, so for internationalized file names.

But I think one thing important to mention about the file system is that there's intentionally no specific affinity to any specific file system. In other words, the file system is designed to be able to deal with any kind of file system plugged in. We actually run and test on UFS within Apple. We don't depend on the fact that it has to be HFS. One of the things that I think Steve mentioned this morning was when you're living in a networked world, you really don't know what's on the end of that wire. You have to make sure that you can run on the lowest common denominator file system.

So from the file system architecture, we do not make any particular affinity to any one of these file systems. Obviously, we think HFS Plus is the best choice, but I think it's important, as you're looking at implementing things that depend on the file system, not to make assumptions about what the underlying file system capabilities and architectures are. There are APIs to help you with this. The file system is also responsible for enforcing the file system security policy, basically making sure that there's a concept of ownership on the entities that are on the disk and reinforcing that with the rest of the Unix security policies.

From the standpoint of what we've been doing in file systems, I think one important thing to note is with Jaguar, we now support up to 15 terabytes for an HFS+ file system. We also have done quite a bit of work with WebDAV, which is kind of what's used for iDisk, if you happen to use iDisk, or if you happen to be working with web servers. It's a common protocol for being able to get file access for that. We spent quite a bit of work working on performance and improving authentication, particularly adding digest authentication to the system. For the file sharing level, we've added Samba, which is basically SMB file sharing capability in the desktop system. So in addition to you being able to turn on personal file sharing and be able to share like you would with another Mac user, you can now turn on personal file sharing and be able to share with a Windows user. And that's by actually having a Samba server as part of the desktop system. We support SMB browsing in various authentication forms now. There's built-in support now for quotas within the file system for HFS and UFS and such. We have some particularly interesting new technology around auto-mounting. If you've ever had a chance to work with NFS auto-mounting, it's an interesting concept of basically where you have a file system that's an area within your file system that's designated as being where your network file services exist. The file services don't actually get mounted until such time as you traverse the path, if you will, where that particular file system is, quote, unquote, mounted on. It's what's called auto-mounting.

And we've enhanced Jaguar to be able to support that for a number of different file system types. So in addition to typical NFS auto-mounting, we also now support this for Apple Share and SMB volumes. And so it's basically possible just going through your file system of live navigating file servers that exist in your network and being able to mount them just by accessing a path.

Our UDF file system has been enhanced to support read/write support now. Another key important performance win is being able to remount remote file systems asynchronously. It's basically done in the background now. If you happen to be on a slow network connection mounting a web dev volume or something like that over modem, you don't have to sit there while the connection occurs. That actually occurs in the background now. on to the networking part of the system.

Networking is also a subsystem of the BSD kernel. We, as part of the BSD kernel, it's basically built on the 4.4 Lite code. A while back, however, we spent quite a bit of time syncing it up with a fairly recent version. And with Jaguar, we've actually brought the networking stack all the way up to being synced with FreeBSD 4.4. It's a socket-based API. This is the native networking APIs and services for the system.

If you want to get the most value, this is the level you should be working at or through Carbon and Cocoa-level appropriate APIs. Key important features for our networking stack include multi-homing support, routing, firewall, NAT mechanisms, network address translation capabilities, and with Jaguar, a built-in support for IPv6 and IPSec. I think a really key differentiator between us and the rest of the Unix community in that respect is how we deal with configuration for networking. Being able to support mobile environments, being able to support environments where you may have a lot of dynamicism in your networking state, that auto-configuration and auto-reconfiguration is a really key part of our networking architecture. We'll talk more about that in just a moment.

As I mentioned, part of the Jaguar work is syncing up with kind of the latest FreeBSD. But I think one probably more important issue in terms of really new features is the support for IPv6. So with Jaguar, v6 is built into the system. It's something you can start taking advantage of. There are actually very appropriate APIs that you can be using in your applications if you're not using a high-level abstraction to make sure that you don't limit yourself to just IPv4 connection capability. And there's a session later in the week I'll mention in a moment which will tell you a bit about some of those new APIs. But it is possible to write your applications such that you can run on both IPv6 and IPv4. IPsec is also now part of the system. What I think it's important to note with IPsec is that it's an enabling technology. This is something that if you're interested in using, One of the tasks as a developer is actually developing the key management and the key exchange for whatever it is you're talking to on the other end of the IP set connection. That's not something that we have built into Jaguar. This is something that is typically very application specific. Again, you can learn a little bit more about that later in the week.

As part of our PPP support, we now also have point-to-point tunneling protocol, the VPN solution that's used within the Windows environment, and there's a client application that's included with Jaguar to support that. I think probably one thing that was really understated in this morning's keynote was the work that we're doing on LDAP. Basically, we are going through a process of transitioning to LDAP being our primary directory services model. You may have heard quite a lot about net info and stuff. That is a term we use to describe kind of our low-level network information services within Mac OS X. But with Jaguar, one thing that's occurring is that LDAP is becoming the wire protocol of choice. So if you're dealing with, you know, environments that already have LDAP, we have LDAP client support, so LDAPv3. And in the server, we actually support LDAP as part of the server product. Basically, you'll see for wire protocol purposes that NetInfo is something that we're phasing out with Jaguar and that LDAP is something that we are embracing very, very strongly.

Another key feature that is rolled in is SNMP support. If you're dealing in a network-managed environment, you'll find having SNMP to be particularly helpful. And as part of our kind of round out some of the other capabilities of the networking stack is our Netboot story. With Mac OS 10.1, we supported Netboot of Mac OS 9 clients. For the Jaguar release, we support Netbooting of Mac OS X clients and the ability to support multiple Netboot images. You may have a lab of machines for a school where you still have some older machines that need to boot Mac OS 9 and newer machines that can boot Mac OS X. And the server side of this will actually support multiple netboot images to be able to support multiple client kinds of environments.

Now, I think probably the most important thing that we've done in terms of networking is Rendezvous. Rendezvous is just really some incredible technology. It's basically brought the ease of AppleTalk to TCP/IP. One of the advantages of AppleTalk was that you could very quickly take a couple of machines or a machine and a printer or whatever and just plug them together and it would just work. That's the kind of experience you want people they have when they're dealing with networking. Well, Rendezvous manages to bring this forward using standard TCP/IP solutions to be able to implement those kinds of capabilities. And it's even better than that because the way it does it is much more efficient and much more capable. It's what we like to call zero configuration networking, and it's based off some open standards called zero-conf that's part of the IETF. There's a number of working groups and things like that that we've been working with. Rendezvous has a couple of three different key layers. There's the zero configuration networking piece.

And you've probably have seen a lot of this already, even in Mac OS 9, or in today's shipping Mac OS X, where when you plug into an environment where there is no DNS server, when you have DHCP enabled, that it just picks-- basically picks a number for you. And it's picking that number out of a well-defined range that's used as what's called a link local address. This is kind of the first baby steps, if you will, of being able to support zero configuration networking, of being able to make sure that the system can communicate even when there isn't network infrastructure around to support you.

The other key piece is the support for being able to actually have services be being referenced by name. And this is built on some technology called multicast DNS. And basically the concept is that when you send out a DNS request today on a conventional network, you're actually talking to some well-known DNS server within your environment. Well, the multicast DNS that's part of Rendezvous actually sends out a multicast request, and and the devices themselves respond if they recognize their name. It's like calling to somebody you know, "Hi, Dean," and Dean goes, "Oh, yeah, that's me," and responds.

It's very much the same concept here with devices, where it's possible to send out a request by name for something and the device says, "Oh, yeah, that's me. Here's how you talk to me. Here's my IP address." This all kind of rolls up into this concept between, because it's rolled into DNS, being able to effectively have services registered and go through this process of discovery. I'll show you an example of that in a moment. This capability, though it works incredibly well in the small kind of ad hoc networking environment, has a big benefit over AppleTalk, I think, in that it's considerably more scalable.

Because it's built on DNS as its way of being able to access services and discover them, that you can actually, in a large corporate environment, use an existing DNS infrastructure to be able to publish all the services and capabilities that you have in your system. The systems don't have to necessarily respond individually. In fact, you just use your existing DNS infrastructure to be able to take advantage of it. And like I said, I'll try and show you a little bit here in a moment.

Obvious examples of using Rendezvous, what you saw this morning, the cool iTunes demo where you could effectively just get applications that can spontaneously share information. That's a very interesting example. Basically you should think of any number of circumstances. iPhoto might be another one where you might want to share pictures. In situations where you'd really like it to be easy for people to very easily exchange information is something where rendezvous really plays a real enabling role. Peer-to-peer laptops is another one. If you happen to meet your friend in the local coffee house or the bus stop outside or something like that, you'd really like an airport connection to be just the fact that the two machines are within proximity of each other, that you should be able to share files very easily without having to do anything. And that's, again, kind of the key concepts that are driving rendezvous. Headless devices are another good example. Obviously, if you don't end up having a display on a particular machine or some device, it gets very difficult to be able to go in there and configure up the IP address and all the various services. Again, rendezvous can play a role where I can discover that particular device and immediately be able to talk to it. And of course, we must rather assume that someone will come up with some other cool thing, some gadget or some other thing that can really take advantage of Rendezvous. So with that, I'd like to do a real quick demo.

Hey, we're up. So the first one is we've-- actually, the engineers, I threw out at them last week, gee, I'd really like to have something to show these guys. It's interesting to talk about, but it's always better to be able to see. And so they ran down to Fry's and picked up one of these cameras. There happened to be a little-- it's a little web camera. It's got a-- Ethernet link at the back, and one of these things that you end up having to go and configure, and what you like to be able to do is just effectively, the way you use these things is use a web browser to go administrate them or to be able to see the image. Well, the problem with a lot of these things is, again, you have to kind of figure out, "Okay, what's the IP address? How do I do this?" The experience for something like this should really end up being just being able to go go to a browser and be able to just select the device. In this particular case, the camera happens to be exporting HTTP as one of its protocols. In Rendezvous, it's important to note it's not just for sharing files or for one particular set of services. It's for any kind of service that you can imagine. Things like web servers can actually publish themselves as being available. In this particular one, it's been set up so that we can do exactly that. And if I go to this little browser, well, poof, there it is. There's my device. It just shows up on the little browser, and I can just click on it and connect. Well, the advantage of this is basically that, as you can see here, it should be live, that getting to be able to connect to this device is really just a matter of being able to discover it in a browser, just like if you use the chooser on Mac OS 9, I can go and select the kind of device I'm interested in, that it shows up, I can click on it and use it. That's the kind of experience that we really want to see for devices that connect to a Macintosh.

The other good example is printing. The kind of experience you expect with printing is, again, like with AppleTalk, you want to be able to just discover the printer. And I think what we'll do is we'll do just a real quick little demo of that. Let's see, we need somebody's name so you believe this is real. What's your name? David. David, okay, great.

So sorry. So with this, you've all seen the Mac OS X print panel capability. It comes up, and then you select your printer. And gee, the printer's not there. Oh, it's not plugged in. So with the kind of experience you get when you get the printer out of the box, really what you'd like to see is that you just plug the darn thing into the printer and the cable in and you go back over and hopefully, oops, you It just showed up. I think the real power of this is what happens here is that as soon as the device is detected, that it publishes itself as being a service.

And that service immediately gets broadcast to the print center. The print center says, oh, there's a printer here. There's only one. Well, here's the one you want. And let's go off and just print that so you believe that it truly works. And again, the experience should be plug it in and it works.

And that's the kind of experience we want to see on the system. for printers, for things like web devices, for web servers, if you're administrating other machines, for file-sharing services, for other things like that. And sure enough, that's David. So anyway, I think the real key with Rendezvous is to try and create that just plug-and-play capability with network-based devices and services on the system. And it's not limited, again, just printers, but anything you can imagine, with iTunes being a really good concept demo.

There we go. So for the networking portion of the system, there's a number of sessions you might want to go to. There's a networking overview on Tuesday, an advanced one, which will get into the IPv6 and IPsec and some of the other key pieces on Thursday. Zero configuration networking.

If you want to learn more about zero comp, this is the session to go to. They'll have a number of demos show you the code or calls that you can make to actually use this stuff. And by the way, the example I gave was using, This is a stock Jaguar system, just the same as the CDs that you have. So you can be able to play with being able to put together little toys and things like that yourself very quickly. The one thing about Zero Configuration Networking and Rendezvous is that the APIs and services that you need to access within your application are incredibly small. It's a very, very simple thing to integrate.

If you're interested in learning more about our LDAP support and our general strategy for directory services, that's on Thursday. And then there's a feedback forum on Friday afternoon. So the BSD application environment. This is kind of where the power of Unix kind of comes into play. This is the command line. Basically, all the application-level APIs and services and tools that really give it the Unix feel. So, you know, the kind of LS and CP and all the kinds of standard things that you would think of. All the daemons that run in the system, the daemons that run in are typically BSD applications, if you will, that run. Things like LDAP happens to be... LDAP is just open LDAP, freely available. And Apache Web Server and things like that. These are all just standard Unix services that run as part of the BSD application environment. Thank you. The one thing that's kind of neat about a Mac with Unix is that you can't do that on a Linux box.

Being able to play your iTunes and have cool graphics and a lot of the other stuff. And as you can see here, kind of an example, there's X-Window support and a number of other things. Being able to have this kind of capability on a desktop and portable system that's available to everybody is really cool. And I think one of the real powers of Mac OS X is the fact that this kind of power sits under the hood and that you can actually be a geek and be proud of it.

So what's new in the BSD environment? Well, one key thing is we've synced up with FreeBSD 4.4. We've spent quite a lot of work to try and bring a number of libraries and other services and things like that up to date. So if you're using our reporting code over, you'll find that we've done a lot of things to update that environment. Bash is now the primary shell on the system.

Those that like the shells, we figured that would be the response. Python is now included as part of the system. We have a new BSD SDK package that's part of the developer tool set. And these are APIs that we really don't advise you writing new applications with. But if you're porting an application from a Unix environment, these are kind of the SDK tools that you probably need to be able to port those apps. Things like OpenSSL, LibEdit, et cetera, et cetera. Again, we don't encourage people using these libraries and services when you're writing a new app from scratch, but if you're porting something, we've been trying to make sure that you have a good collection of tools in your tool bag to kind of ease the process of porting to Mac OS X. We've also, as part of Jaguar, kind of rolled in the latest versions of Apache and Perl and Emacs and, you know, the various kinds of tools. Lots of new and updated man pages. We were very weak in the man page space before. Thank you. So put a lot of work into trying and getting a lot more of those that we're working, continuing to work on that. I think the other important thing is that we've, If you're familiar with the BSD command space or in the Unix list, there's a number of different ways to authenticate yourself in from the command line.

And in the Linux and FreeBSD worlds, they've all kind of standardized on PAM, the programmable authentication modules, as a way to provide some consistent way of being able to deal with kind of the Unix tool space. Well, with Jaguar, PAM is now how all our commands and tools are also handled for Mac OS X or for Jaguar. But we've also integrated PAM upwards into the security framework so that the authentication mechanisms and processes are consistent, whether you're using the login window or you're using Telnet or whatever, or anything down at the command line. They all integrate and use the same set of services back and forth. And in addition, for the BSD environment, we've added a number of other portability APIs and services, Again, to try and make it easier for people who are coming from other Unix environments to move to 10. For the terminal, we've also done a number of things. This is another one of those things that probably mom will never see, but if you happen to do a lot of work at the command line, we've done quite a lot with the terminal application. Support for full UTF-8 character support. As you can see here, from the terminal line, you can deal with multiple languages. as well. It's all at SUI rendering, so we get a number of the benefits, alias to non-aliased, alias to font rendering. We've done a lot of work on the emulation code, basically spent time making sure that we are, in fact, as good, if not better, the next term in terms of our terminal emulation.

Thank you. And there's support now for a split window scroll back so you can have kind of your active window and be able to look at the scroll back information in case you're trying to track a problem in a build or something like that. And a number of kind of real-time preferences and things like that so you can change the behavior of your terminal windows a little bit more effectively. So if you get a chance to with Jaguar playing with the new terminal app, let us know how you like it.

For those of you that are Unix, you know, kind of the Unix developers coming to the Mac platform, I'd really encourage you to go to the Mac OS X overview for Unix developers. Again, this is kind of gives you the Mac OS X perspective from assuming that you're coming from a, you know, a Unix world. And if you're looking at porting Unix apps to Mac OS X, just in general, we have another session also tomorrow, which will help a lot on, you know, how do you bring an app over? What's our build environment? what's different. If you're porting something from one of the BSDs or something like that, what's involved?

Moving on to security. This is part of the OS framework layer of the system. Our policy on security is first and foremost, let's ship a system that's as secure as we can, and if you want, you can enable services if you need them. That way, mom doesn't have to become an expert at becoming a security administrator. That should never have to be the case. So I think one important thing from our philosophy is that when we're dealing with security in Mac OS X, that we really like to think of things as being secure out of the box, unlike most of the other systems, which is everything's turned on, and if you want to make it secure, you go through a very long list of steps to secure up your system. Another key part of our security layer and infrastructure, though, is that we clearly need to be able to work with the rest of the world. There isn't any one particular solution for security and authentication.

Our security infrastructure is designed to be very configurable, very much based on standards, basically provide a whole series of libraries and services to really try and allow you to integrate security capabilities within your applications. So a lot of the services that exist are designed with these concepts in mind. Of course there's the keychain, which is very much an ease of use capability of our security system. Single, basically the ability to remember common logins and to keep them all together in one secured place.

Disc images is a high-level feature, but it's an important thing if you happen to have one of the little USB dongles or things like that, being able to put an encrypted disc image and keep all your important information. Even if it gets stolen, they can't get to the contents. Within the actual services of the security frameworks is a set of capabilities for being able to support pluggable authentication. For Jaguar in particular, this has now been integrated into the login window. From the login window, if you have Kerberos enabled, you have a single login to be able to support Kerberos environments, as well as other kinds of login authentication solutions, such as smart cards or other kinds of things. It's a pluggable model to be able to support multiple kinds of authentication solutions. Another key service of the security system is being able to do certificate management. And it's one of the key new features for Jaguar. And there's a session later this week on that I'll mention in a moment. And then there's secure transport, which is really our answer to OpenSSL. And I'll talk about more of that in just a moment as well.

So like I said, we've integrated Kerberos now into the system. There's support within mail and FTP and login and a number of kind of system services to, you know, support Kerberos throughout. It's not just a kind of an add-on thing. We've been working with the folks at MIT on this.

They've been great partners to work with. We're basically have integrated the Kerberos for Macintosh 4.5, which has Kerberos v4 and v5 support. And again, this is integrated and into a number of the other services that exist. So if you happen to be in a Kerberos environment, you'll find this to be really helpful.

I mentioned PAM already, but it's worth restating that these two environments actually work together, so both at kind of the Unix level and at the high-level application level, that you have one consistent set of behaviors that occurs as far as authentication is concerned. If you're porting a Unix app and it's PAM-enabled, you'll fit right in.

uh... and then i want to spend a moment talk a little bit about c_d_s_a_ in a particularly secure transport CDSA is the Common Data Security Architecture that's basically kind of the key, if you will, framework, if you will, for security libraries. CDSA provides services for encryption and authentication.

It's an incredibly rich set of services. It's based on an open standard that is managed by the open group, and the CDSA code is actually something that we, in addition to the rest of Darwin open sourced a while ago. So it's basically very much a key part of the system for being able to handle authentication.

But what's important about CDSA is it's much like our file system has no particular affinity. The same thing applies to CDSA. It has no specific affinity to a given authentication model or a specific encryption. Its job, in fact, is to be able to provide kind of the abstraction for those kinds of things. The advantage of that is that as things improve, and boy, there's a lot of stuff happening now with smart cards and other types of environments that exist out there, that CDSA is our way to be able to make sure that we can continue to plug into these different types of environments, and is what we recommend people use when they need to be able to do encryption and authentication services. A prime example of this is OpenSSL. OpenSSL is one of these very well-known open source solutions for being able to have secure sockets communication, like for a web browser or something like that. And it's actually a very good solution. It does an excellent job. But where it falls down is that it's kind of implemented in one solution. It has no certificate management in it. It has no way of being able to support like a smart card authentication or other things. And if you write an application using OpenSSL, well, you probably can get a great connection to your web server, but if you ever want to improve, if the encryption technologies improve or if you ever end up having new authentication solutions that you want to be able to support, OpenSSL won't handle that for you. And that's where secure transport and CDSA come into play.

We're really trying to work, in fact, with the open source community to promote CDSA is really the better solution and kind of our working with that community at large. Since CDSA is also open source, we think it's a much better long-term solution. And then another key set of security services for Jaguar are certificate management. We've done, again, there's a lot of work here, support for X.509 and various UI services and stuff for being able to support for both Carbon and Cocoa, basically to try and make sure that if you're in an environment where you're dealing with certificates, that you can more adequately be able to support them. Then there are sessions later this week that will go into more how to take advantage of these capabilities. Mm-hmm.

So one thing about security before we move on is packaging your products. One of the things that I've noticed as a user of Mac OS X is that many times folks who are writing the software or porting it to Mac OS X forget about the fact that it's a multi-user operating system. One of the things I encourage you to try is make sure that when you install an app in your applications and you're working on your installers, that you make sure you install it as one user, log out, log in as another user, and try and make sure that the app still works and behaves and was installed correctly. When you're in a home environment, you know, the parents most likely will install some application, and then they want the kid to be able to log in and use it potentially, or not.

But you want to make sure that if you intended your app to work for everybody on the computer, that it truly does. So always remember that it's, you know, down at the base of Mac OS X, it's a multi-user OS. Test and make sure your installs work that way. File system issues are another big item that we see a lot as an issue. Particularly file system ownership is very important.

You want to make sure that that app you install, again, if you intend it to be able to be used by other people on the computer, that the ownership of the file is such that it's possible that somebody other than who installed it can execute it. And that permissions are really even more important. This is an opportunity, unfortunately a very bad opportunity, that people have of being able to create security holes in the system. Make sure that your executables aren't world writable. It's amazing how many of those we've seen. Or worse yet, that you have an executable that set UID root. In other words, it effectively has complete privileges on the system and is also world writable. This is bad. You really need to be thinking about security when you're packaging apps. Not just how your app uses the system in a secure way, but how you actually deliver it to your customer is really important and is something that's really different with 10 than it was with 9. And I encourage you to spend a few extra moments to think about that. In addition, and we talk about set UID applications or applications that effectively say that they have to be root in order to be able to use services in the system. 99% of the time, that's not true. There are ways to get to the services that you need, most likely. We can help you with that. Instead of doing something horrible, like making a potential security hole for yourself and for your users, come talk to us.

The authentication, you know, frameworks, the security framework has a bunch of ways that, you know, will support being able to access the system in much more controlled ways. There are other services that can help you. Come, again, come talk to us. If you really need that, maybe it's something that we need to add a service in the system for you. We really want to discourage people from being able, from shipping applications that require Set UID. And even internal to Apple, we've really kind of brought down the gauntlet on our own internal development because it's a strict rule to really limit the Set UID apps that are in the system. They are a real opportunity for trouble.

So for security, if you're interested in learning more, there's an authorization session on Wednesday. The CDSA and secure transport, if you're doing anything that you're using OpenSSL for now, go to that session. You really want to be using CDSA and secure transport. There's also a session on certificates and certificate management and UI on Thursday, and a whole session on Kerberos, if you're involved in that. And there's also a dedicated feedback forum for security.

So the vector and math libraries, these are also part of my organization at CoreOS, and it's one of those things that may not be as visible, but this has such an impact on the performance of the system. The capabilities of iMovie and iTunes and things are all built on the vector and math libraries we have. Basically, they're a set of highly tuned, both vector and Altivec, vector, rather, AltaVec-tuned libraries, as well as scalar math libraries.

And there's a set of libraries for doing things like DSP, the VBLAS, the basic linear algebra, and a number of other libraries that are in the system. If you're doing anything where you're doing data transformations or you're really trying to take advantage of the Altivec, chances are you can probably do it using these libraries without having to go in and do your own vector code.

With Jaguar, there's a lot of work that the team put into and LibM or the Math Library V5 to make them just absolutely top-notch fast and as well as making sure that they're IEEE 754 and C99 compliant. There's additional features that were added to the BLAS library, specifically double and single precision and real and complex data types, and additional VDSP services, double precision fast Fourier transforms and 2D FFTs and such. If you're doing, again, things where you're doing a lot of DSP work or things like that, you want to check these things out. Thank you.

Just to throw a slide here from a performance standpoint, this team is really proud of the work that they do in terms of performance on the vector engine and the vectorization libraries. And for good reason. They're getting 2x performance on a number of these libraries. If you look, this is a 1 gigahertz G4 machine versus a 2.2 gigahertz P4, and we're still getting twice the performance. That's pretty incredible. Again, some great stuff there. So if you're doing a lot of work with the... that use the vector engine, make sure you check out these libraries. There is a whole session on the velocity engine and performance optimization on Tuesday. I encourage you to go to.

Now, one thing that may not have been clear is that all of the technology, for the most part, with some exceptions, but with most of the technology within the Core OS or Darwin, is actually all open source. Open source is something that we initiated as a key kind of strategic drive for our operating system technology a couple of years ago. And Darwin's been around for a little while now.

Apple's very serious about open source technology. We leverage the open source community, but more importantly, we make sure that the whole core of Mac OS X is available as open source. We're the only company of our type that is actively depending on open sources as a key part of their commercial business solution in this way, and working with the community, in fact, in making sure that this works. It's important to note that we use the term Darwin and Core OS completely interchangeably because they are the same. We open source the whole core. You can go out and build the Core OS of Mac OS X and actually slip your own built version under a shipping version of the system. We don't encourage you to do that with your customers because you get to support it. But it's something that technically is possible and it will allow you to actually go in and work with the technology that's part of the system. And more importantly, participate in evolving it, developing it. There's a number of projects that are supported in our open source efforts. Not only Darwin, the core of Mac OS X, but the Darwin streaming server, basically the streaming technology, what you affectionately know as the QuickTime streaming server that was released a while ago, but in the open source community it's known as the Darwin streaming server. That's been ported to a number of different platforms. OpenPlay, which is a kind of network abstraction for network gameplay. The CDSA framework that I talked about a few moments ago, and HeaderDoc, which is basically source code documentation tools. So please come be part of our open source efforts. There's a handful of new initiatives we have around open source. One is we just launched last week with the Internet Software Consortium, opendarwin .org, and it's basically a way for even more people to participate in our open source activities.

It's basically not controlled by Apple. We've basically helped get this set up and have been helping with the process, but are really trying to make sure that there's a way for community involvement and the community to really drive the open source activities. Our Darwin, the opensource.apple.com is still, and Darwin is still the reference open source platform and drop, the source code drop, but the Open Darwin initiative allows even more people to participate. There's a couple of new projects that are now part of our open source initiative. Open Directory, so all our directory services infrastructure has now been open source, as well as CUPS, the common Unix printing system.

So with all this, there's actually been a huge amount of progress by the open source community. A lot of stuff that we've actually got in Jaguar, particularly things we've upgraded as far as in the Unix base, has been as a result of our collaboration with that. A lot of people have been contributing directly. But there's also been people who have been porting some interesting stuff to the platform. As you might see here, OpenOffice has recently been ported to Mac OS X.

We'll talk a lot more about open source and kind of the initiatives and how you can get involved in the infrastructure and all that kind of stuff tomorrow afternoon at the open source Apple and You session. Come join us. Thank you. So a few last thoughts. We spent a bit of time just giving an overview of the Core OS. The purpose is you know what the technologies are. You know what's underneath the covers. But you should always develop to the highest level abstraction you can. Try to avoid using the low level APIs and services unless you absolutely have to. There are great abstractions for a lot of these things in Carbon and Cocoa. But many times there are things that you can only get to through getting access to lower levels of the system. And I think it's important to know what the building blocks are, because it does impact the behavior of the system. Remember, Carbon and Cocoa and all the rest of the environments are all built on top of these foundations. So fundamentally, you know what's at the bottom, and there's the source to all of that, the stuff at the bottom that you can see in case you really want to know how it works.

Performance on a modern core, well, performance is always important. Everybody knows that. But on a modern core, it's even more important. And the reason is because it's much easier for you to be able to have impact on many things that are happening in the system. Because it's expected that there's a lot more concurrency going on, that things are multi-threaded, that there's preemption, that your behavior can actually impact the real-time performance of other things on the system. And it's very, very critical that you consider performance, you know, in the design of your applications.

We have a session this year just on this subject, and it's filled with lots of great tools or tips and tricks and a bit of understanding of kind of what the issues that are kind of different in dealing with performance, and I'll point to that in a moment. It's also worth restating this. Rendezvous technology is really something pretty neat. You want to look at this as an opportunity to really create something really spectacular with your applications. The ability to be able to do sharing is pretty critical. The work that was done by the iTunes team didn't take them very long to be able to implement the ability to share tunes between multiple users. Spend a few moments and think about, outside of the box, if it were just painfully easy to be able to support being able to collaborate as part of your application. This is where Rendezvous comes into play. It can really enable a new class of application.

Always think about security. This is something that's new with Mac OS X that really wasn't as big of an issue for 9. We have so much more capability in this system, but we also have new things that you need to factor in, multi-users, permissions issues, other security issues. It's important to factor those things into your applications. And again, this is an area where we can help you if you're not sure. And lastly, we really would like you guys to become part of the Darwin community meaning not only to use the technology as part of Mac OS X, but we have a lot of infrastructure to support open source development, and it means, you know, unlike, you know, Mac OS 9 and before, you can actually have a direct impact on the development of the Core OS of the system. It's open. We actually encourage your participation actively. We, you know, it's even, we have developers who don't work at Apple that have right access to our CVS repositories and actively contribute to the development of the system. You can too. We'd really like you to be part of it. Amen.

So one last set of pointers off to some other sessions. We have this developing for performance session on Friday. This will be a great session, strongly encouraged. There's a feedback forum for all of the Darwin Technologies Wednesday afternoon, the security feedback forum, of course, on Thursday, and the networking feedback forum on Friday. And you can get a hold of me if there's something that comes up for as far as the Core OS is concerned.