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

I think this picture actually kind of 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 kind of 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 little bit about what we've been doing as far as Jaguar is concerned and the kinds of services and facilities that you'll 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. 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. A lot of our job is to really be as invisible as possible to everybody, because we are that plumbing in the walls and the stuff on the bottom. For Jaguar, we've been doing a bit of digging of some things up and 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, it's very highly integrated into the rest of the kernel environment.

Its job really is to be able to be 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 Mach's concepts of tasks and threads. And that all memory management in the system is built on top of Mach. 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. And you'll see bits and pieces of Mach 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 Mac, on top of Mac, or tightly integrated with Mac, 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 Mac Kernel is based on the BSD 4.4 Lite, plus we've spent quite a bit of time integrating it with Mac and I/O Kit, our IO system.

It provides 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, enforce various forms of ownership and permissions. As I mentioned, it really is responsible for providing the OS personality, if you will, of the system. All of the high-level APIs for the OS are ultimately exported through the BSD APIs.

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 and jot it all down because there's actually useful information in there. Well, one of the things we've done with Jaguar is actually capture all the state of a panic.

And 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... the panic state information, and this actually gets logged into the crash catcher 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... Right now... As of... Today, you can... 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... Yeah.

exciting stuff, as far as performance work is concerned. And two primary things. One is what we call an application... Basically, an adaptive application profile. And what ends up happening is, 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, you know, a profile of what occurred during the launch.

And the next time you launch that application, the kernel will actually take advantage of the fact that it knows, and is able... 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 a... what we call a working set cache, where basically an application's, you know, set of hot pages that are being used to execute the application are kept track of. And when you swap between, you know, or context switch between multiple applications, the kernel will actually... the kernel will actually be very smart, again, about being able to try and keep, you know, the right things in memory, so you're not spending a lot of time reading and writing process state.

And, of course, again, there's this kind of caching process... or the... being able to do read-aheads and other types of collective IO behavior. In the P-threads 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... a number of additional P-threads APIs to kind of fill out the POSIX, you know, compatibility suite.

One thing to mention, if you happen to be someone who is developing in the kernel, we have, you know, there's 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 IO-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. You absolutely have to. And 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 Mac 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.

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. There's this concept of families, which provide the protocol 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 a disk device. And so the families provide the APIs and services that are 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 available for you, the developer. You want to go to the KEX management session later in the week to learn a lot more about what those things are. 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. One thing you should probably note is GCC3's C++.

ABI is actually different than what shipped in Mac OS X. The good news is that this is something that the I/O Kit team really considered from the get-go. If you have existing drivers that ship today under 10.1, under the old 2.7, 2.97 compiler, I/O Kit automatically handles the patch-up and keeps everything so that it's binary compatible, it's upward compatible.

It is important to note that if you write a device... ... driver on Jaguar later, that it will not be backwards compatible. That's something to factor into your development processes. One other area of enhancement within I/O Kit is the power management system. There's been 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 kind of 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 all 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 was responsible before.

As you heard this morning, Steve mentioned we have some directions. We'll hear more about that next week as far as servers are concerned, but there's a lot of work that IOKit'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.

That's 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. 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 a 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 IO 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. A 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, etc., etc., WebDAV, which is a web-based file system architecture, UDAF, 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.

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.

So you have to make sure that you can run on the lowest common denominator file system. From the file system architecture, we do not make any particular affinity to any of the file systems. Obviously, we think HFS+ 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. in 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 Plus file system. We also have done quite a bit of work with WebDAV, which is our web 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. And 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. 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. And if you want to get the most value, this is kind of the level you should be working at or through Carbon and Cocoa-level appropriate APIs. Kind of 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 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. And we'll talk more about that in just a moment.

As I mentioned, part of the Jaguar work is syncing up with 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 IPsec 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 NetInfo and stuff. That is a term we use to describe 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. If you're dealing with environments that already have LDAP, we have LDAP client support, so LDAPv3. 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. Part of our round-out, some of the other capabilities of the networking stack is our NetBoot story. With Mac OS X-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. The server side of this will actually support multiple NetBoot images to be able to support multiple client kinds of environments.

I think probably the most important thing that we've done in terms of networking is Rendezvous. Rendezvous is really some incredible technology. It's basically brought the ease of Apple Talk to TCP/IP. One of the advantages of Apple Talk 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 to have when they're dealing with networking.

Rendezvous manages to bring this forward using standard TCP/IP solutions to be able to implement those kinds of capabilities. 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. It's based off some open standards called ZeroConf 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. You've probably seen a lot of this already even in Mac OS 9 or in today's shipping Mac OS X. When you plug into an environment where there is no DNS server, when you have DHCP enabled, it just picks a number for you. It's picking that number out of a well-defined range that's used. It'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 being referenced by name. This is built on some technology called multicast DNS. 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.

The multicast DNS that's part of Rendezvous actually sends out a multicast request, 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, because it's rolled into DNS, of 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. 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. That's, again, 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 it can discover that particular device and immediately be able to talk to it. Of course, we'd 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. 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 web camera.

It's got a-- Thank you for joining me. I'm going to go ahead and start off with a quick question. I'm going to start off with a quick question. One of the things that I've been thinking about is, as you mentioned, the web browser, the browser that you use to go to a browser, how do you do that? 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 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. And things like web servers can actually publish themselves as being available. And this particular one'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. 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 have it discovered in a browser. Just like if you use the chooser on Mac OS 9, that 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. And that's the kind of experience that I've been having. And I've been able to do that. And I've been able to do that. And 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. 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 know, you've all seen, kind of seen the Mac OS X print panel capability. It comes up and then you select, to go select your printer, and, gee, the printer's not there. Hmm. Oh, it's not plugged in. So, you know, with the, you know, the kind of experience you get when you get, you know, the printer out of the box is, you know, really what you'd like to see is that you just plug the darn thing into the, you know, into the printer and the cable in and you go back over and hopefully, oh.

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 kind of anything you can imagine with an iTunes, I think, being a really good concept demo. So let me go back to slides.

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 ZeroConf, 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. One thing about ZeroConf, the 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 the 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. LDAP is just open LDAP, freely available. Apache Web Server and things like that. These are all just standard UNIX services that run as part of the BSD application environment.

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. As you can see here, an example is X Windows 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. 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 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 getting a lot more of those set. We're working, continuing to work on that. I think the other important thing is that we've...

Thank you. And there's support now for a split window scroll back, so you can have 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 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 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 kind of gives you the Mac OS X perspective from assuming that you're coming from 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 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, and there isn't any one particular solution for security and authentication.

So our security infrastructure is designed to be very configurable, very much based on standards, and basically provide a whole... a whole series of libraries and services to really try and allow you to integrate security capabilities within your applications. And so a lot of the services that exist are kind of 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 kind of keep them all together in one secured place.

Encrypted disk images is a kind of... it's certainly a high-level feature, but it's kind of an important thing if you happen to have one of the little USB dongles or things like that, being able to put an encrypted disk image and keep all your important information. Even if it gets stolen, you know, 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.

And for Jaguar in particular, this has now been integrated into the login window. So 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 there's... it's one of the key new features for Jaguar, and there's a session later this week on that I'll mention, 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 system services to support Kerberos throughout. It's not just 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 basically have integrated Kerberos for Macintosh 4.5, which has Kerberos v4 and v5 support.

Again, this is integrated into a number of the other services that exist. 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, both at 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.

And then I want to spend a moment and talk a little bit about CDSA and particularly secure transport. CDSA is the Common Data Security Architecture that's basically the key framework 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.

And 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. It's one of the best 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 as really the better solution. And kind of are 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 X509 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. And then there's sessions later this week. Whoops. There's sessions later this week. There's a lot of sessions later this week that'll go into more how to take advantage of these capabilities.

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, 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, 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 it's a... 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, you know, 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're intended to be able to be used by other people on the computer, that the ownership, and 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. And 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, you know, world writable.

You know, 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 it's something that's really different with X than it was with IX. 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 the 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. 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, you know, shipping applications that require set UID. And even internal to Apple, we've, you know, really kind of brought down, you know, the gauntlet on our own internal development. Because it's a, you know, 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, CoreOS. 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 are a set of highly tuned, both vector and AlteVec, or vector rather, AlteVec-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 AlteVec, chances are you can probably... 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.

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 GHz G4 machine versus a 2.2 GHz 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 that uses the vector engine, make sure you check out these libraries. There's 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 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. And we're the only company of our type that is actively, you know, depending on open sources as a key part of their commercial business solution in this way, and working with the community, in fact, and 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, you know, 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 I know 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 and 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 Hederdoc, which is basically source code documentation, and the open source application 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 kind of helping with the process, but are really trying to make sure that there's a way for people to participate in our open source activities. 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 opendarwin initiative allows even more people to participate. And there's a couple of new projects that are now part of our open source initiative. Open Directory, so all our directory services infrastructure. There's 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 space, 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 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. 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.

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. You can get a hold of me if there's something that comes up as far as the Core OS is concerned.