Allchin:
We have a broad vision that ties together a few dimensions. One dimension
is the basics: quality, robustness, reliability, scalability, and security. We will continue to improve on those basics.
A second dimension is communications. I'm wiring communications into every nook and cranny of the system so it becomes a great citizen in transient networks. If the connection drops or if you move between cells, the system should still work with the network. The system needs to figure out what protocols are on the network automatically. It needs to understand whether it is going over a low-latency or high-latency network. It needs to understand how to take advantage of the quality of service that may exist if you are doing video streaming. If it has an error on a network, it needs to automatically reconfigure. The programming model I'm promoting is that the network is broken all the time. People design their software so that if you communicate at all, it's a miracle.
The last dimension is ease of use and simplicity. Systems are too difficult to use. I would feel much prouder of
the computer industry if there were not so many arcane things hidden in software. We present error messages that somebody can't do anything with. The system could recover from more errors if we worked harder on it. And the system could be much more intuitive. We clutter the screen with many options, and the system isn't adaptive to what the users are doing.
Whether it's consumer or business makes no difference: Everybody wants simplicity. We want an environment that is much more helpful and much more intuitive. Intuitiveness is more than intelligence. The system should be able to follow what's going on and make proposals. You've seen some work in that area in some of our applications and the answer wizard, but we're just starting to scratch the surface.
If I tile these three dimensions together, the result is being maintenance free. There is no reason machines can't just do much more cleanup. I mean, I hate utilities that run after the fact that have to clean up temp files and other things. It's
unnecessary. The system could be much, much smarter. It should be able to automatically manage space, and if it does run out of space, it should be graceful. You want your system to basically be foolproof.
BYTE:
The average system has thousands of DLLs and device drivers on it. When you talk about achieving simplicity, are you saying you can create a layer that manages that complexity?
Allchin:
No. Layers are nothing but more overhead: You can put lipstick on a chicken, but it's still a chicken. We don't think apps should have to go through an install process -- it should be seamless. As far as having lots of DLLs, I think about it like this: The fact that you can see any of this stuff is like looking through a transparent TV where you see all the transistors and chips and ICs. The end user shouldn't see that. TV manufacturers don't encourage you to open the case, stick your finger in, and try to pull out a transistor. Well, that's what happens if you try to d
elete a DLL. We've created an environment that can get into trouble, and we can change some of that. There are still going to be device drivers, but we'll apply some here-and-now technology like Authenticode to sign them so customers are assured of a certain quality level.
BYTE:
Some of what you said reminds me of the best years of the Mac, where you put stuff in and it would install itself and it actually worked.
Allchin:
First, the mac is super-primitive. I hope that nothing we are doing will be compared with that. The Mac was a joke architecturally. Come on -- virtual memory? We have to have a rich, solid infrastructure for how apps deal with the system. The problem with the Mac is that it was too closed. It wasn't an open environment that people could innovate in. And if you didn't use a particular tool set from Apple, who knows whether it would work properly? It wasn't an industry: It was a closed world.
BYTE:
At one time, you
were talking about an object file system as part of Cairo; now, you're silent on the matter. Has that idea gone away?
Allchin:
It hasn't. In NT 5 we will deliver basically all the functionality we talked about in OFS. Just think if we renamed OFS as NTFS [NT File System], which is basically what happened. So NTFS 5.0 will have quotas. It will be attributed, meaning you can have properties tied to streams in the system, and arbitrary properties tied to files. And it will be automatically indexed on properties and content. It will have distributed link tracking, so if you point to a link or if you have a link embedded in a document, we will automatically track down that document.
We are pushing three dimensions in terms of storage. The first is location independence. We are doing some in Dfs [Distributed File System] now. We want to be able to migrate data between the client and the server transparently. The last thing we're focused on -- and we have a team definitely cranking on thi
s -- is merging database technology with the file system to get a more unified storage system. It will not replace the super-high-end OLTP environment, but our goal is to be able to offer programmers a rich storage system that is available everywhere.
BYTE:
Are you going to create an object file system? If so, what sets an object file system apart from a regular file system with these extensions?
Allchin:
I think it's all semantics. When I talk about an object, it's got a data type and you can automatically bind to the code that is associated with it. Make links fundamental to the architecture and you can do things like link management automatically. You can surface this storage environment up into a programming language, so you can deal with the object in a seamless way in a programming language. So it's just a question of binding the programming language to this environment.
People are doing that today, and it becomes a question of the granular size of
the data. Some types of data -- integers, for instance -- may be small, and the storage system may not be good at storing them. NTFS certainly is not good at storing integers; it needs reasonably sized pages.
When we did OFS, we thought the object sizes were going to be fairly small and spent a great deal of time packing the node items densely. It turns out that was a mistake: Most things people deal with -- take an HTML page -- are fairly large.
But when you ask will we ever build one, I think NTFS is in part an object file system. It doesn't have the surfacing binding into a language, but we have some people looking at that. I think there are many other things that can be done to the storage system. We want to reduce the number of stores that we have on the system. NT 5.0 offers a step in the right direction. Now we have a very large team between the SQL group and the file system group that is working on continuing that movement for the future.
BYTE:
How are you goi
ng to handle information that's stored in different formats -- or even executables that are stored within documents like Active Server Pages?
Allchin:
[For the first one] you will end up with a common interface that will enable you to access the directory, address books, SQL, the file system, and Exchange. And in terms of being able to handle the dependencies and to understand the code, we're scratching the surface in NT 5. There is a class store as part of the directory. You use the directory to find snippets of code and how to automatically download those and how they should be run. But we have a broader vision -- which is still early -- where we are looking to do a repository.
BYTE:
How does a security system have to adapt for today's sometimes-anonymous/sometimes-not intranet style of computing?
Allchin:
We once envisioned that eventually there would be a community of kiosks, and we thought that public key would be the answer there. W
e thought people would have smartcards and walk up to the kiosks [and use them], so we would have to do some sort of authentication to be able to customize the environment we would show. This big-directory-in-the-sky idea did exist.
What have we done? As you probably know, in NT 5 we will have a mapping of public key-to-private key IDs. We think it's a pretty efficient and smart thing to do. You're going to want to know who's coming into your site. You're going to want to be able to tailor the information for them. That implies there's a directory. So when we're testing the directory that will be in NT 5, [we're testing with millions of entries,] not a thousand. I believe that you will see more and more authenticated users because the Internet is going to turn into a good transfer environment -- something that people count on even if it's not good.
BYTE:
What's the direction the directory has to go in now?
Allchin:
It goes back to the dimensions I talked
about, [especially greater intelligence]. Instead of having the user or administrator try to figure out where a replicant should be, why doesn't the system just figure it out? We'll be working on performance, and we'll be working on tools to make schema changes even simpler than we are going to make it in the first release. I can also think of integration with the storage system being even tighter. We're definitely banking on it. Hopefully we've learned by watching others and having our own experience with the current NT directory. Some of us have a little background in that area, so we think we're going to come out okay.
BYTE:
Are the improvements we've talked about a five-year project? A three- year project?
Allchin:
I don't think that anything I've talked about is five years out. It's just a question of how capable we can make it. In other words, it can come out in intermediate milestones; it'll be in NT 6, and from a technology perspective it may be used
in several different products. But certainly it is going to happen. We'll continue to move ahead. NT 5 will have quality-of-service support in it, but we'll move that ahead further in NT 6.0. It's just one step at a time. You know, NT 5 is a big release, and we think we have a fairly reasonable number of people working on things beyond NT 5. Things like this repository, things like the storage that we've been talking about, things like the end-user simplicity -- those things are now being thought about.
Mark Schlack, Editor in Chief,
mschlack@bix.com
NT's Challenges: Microsoft's Solutions
