Fundamentally, if you care about scalability, you need locking for managing your resources, regardless of whether you have a microkernel or a monolithic one, because the on-disk data structures are a shared resource.
You need locking if you want to have things run in a multi-threaded way. However, I would argue that it is much easier to design and manage your locking protocols when you (you includes the development team for your server) are the only ones who have to really understand them and use them.
With this, you reduce the chance that code outside of your driver but inside the kernel could write to your driver's address space, which isn't, in practice, a common occurance, because other code generally won't have pointers that go there.
When a pointer can be created from an integer and when you have functions like "strcpy" which will run happily through memory if you don't have a terminating null, you have a lot of chances for other code to overwrite your data structures. What is this "your driver's address space" you speak of? Doesn't exist in a monolithic kernel. You might have pre-allocated a bunch of space for yourself to use, but it all comes out of the common pool(s) and it's all in the same address space.
That's the whole point! Actually, in Java, from the OS's point of view they're all running in the same address space. From the inside the language point of view, each field has its own little address space with access control on it. It's much finer grained than what the processor gives you and it runs a lot faster.
One might recall that in Smalltalk, the granddaddy of object oriented programming languages, there are no function calls - they're called "messages".
In microkernels you constantly have to worry how to share data with other threads as you can't trust them to give even correct pointers! This is not unique to micro-kernels. A multi-threaded monolithic kernel has the exact same issues, especially when it is running on true multi-processor hardware. This used to be why kernel guys got the big bucks - now there's a bunch of people who do it for free.
Well, as someone who has been involved in the development of both monolithic and micro kernels, I suspect that I do know something about the subject.
Linux, despite being monolithic, has nice layers inside the kernel and clean interfaces too.
I think you missed Linus' point which I agreed with as well. The real thing you want out of a micro-kernel is memory protection between components of the kernel. The rest is just window dressing.
Linux does *not* have that.
Don't confuse run-time separation with interface separation. The latter is a language feature, not a system feature - you could still have a wild pointer and modify private members of any classes directly.
Let's take a look at OOP and *what* your address spaces are doing for you. Now, in a language like C++, the internal structures of an object are only partially protected. As you say, you can go ahead and cast a pointer to an object to a char * and do anything you feel like to it. The memory protection between objects is not enforced fully.
Now, if you look at Java or C#, the runtime is a virtual processor and it keeps you from violating the rules that an object defines on its data structure. The memory protection is *very* fine grained as it is on the field level rather than on the page level. You cannot (repeat cannot) go modifying the internal structures of objects if they are not marked as being accessible to you.
Having spent 10 years as a kernel developer on a day-in, day-out basis, my frame of mind when I stopped doing OS development for a living was very C based. Since then I've spent a lot of time doing OO development and I think that I've broadened my horizons a bit.
When you look at the way micro-kernels are usually conceptually designed, it's from a C/Unix mind set. Separation is done on a "server" basis and the servers export API's. As you try to add more functionality to the server its API starts getting bigger and bigger and uglier and uglier. For example, you might have a file system server. Locking a file would mean adding a call to the API to lock a file. If you try to make something like a "buffer cache server" which all of the file systems could share it's going to have a nasty API and be slow to boot or it won't be able to enforce memory protection well because the conceptual memory protection is being done on a process level.
When you look at this from an OO perspective, what you see is that the objects being dealt with are "servers" and they are too large. They need to be decomposed into their functional pieces and additional objects exposed. A "buffer cache server" would hand out "buffer objects" which had a memory protection level, locks, etc. built in.
Building a kernel that run inside of some protected runtime environment similar to the JVM would enable you to do this. If it were popular enough the features needed to make it really fast would get moved down into the hardware. As it is, I think that the speed of the kernel is kind of a red herring. In general the kernel needs to do fast I/O and fast switching between user tasks and for any other functions the speed probably doesn't matter much. When I was doing kernel development on supercomputers, most supercomputer kernels were single-threaded, even though the machines were multi-processor and things still ran pretty quickly. That's because most supercomputer apps spent very little time in the kernel. I believe this is true for most desktop apps as well. Business and "server" apps tend to spend more time in the kernel, but mostly because they are doing lots of small I/O's.
Unfortunately there's not a lot of room for innovation in the OS arena so we may never see what could be done. That's one of the reasons why I got out of OS development.
And where do you spend most of your time executing in the BeOS kernel? The high-level libraries and the servers I would bet. The micro-kernel is probably implemented in C because C lets you get close to the hardware easier.
The real issue, and it's really fundamental, is the issue of sharing address spaces. Nothing else really matters. Everything else ends up flowing from that fundamental question: do you share the address space with the caller, or put in slightly different terms: can the callee look at and change the callers state as if it were its own (and the other way around)? This is a good insight.
The fundamental result of access space separation is that you can't share data structures. That means that you can't share locking, it means that you must copy any shared data, and that in turn means that you have a much harder time handling coherency. All your algorithms basically end up being distributed algorithms.
This is not a good insight.
If you look at object-oriented programming, access control on data structures is a basic requirement. This does not turn every algorithm into distributed algorithms and it makes locking termendously easier, not harder (since each object does its own locking).
The problem that one runs into in the hardware is that hardware level access control is not very fine grained and it can be pretty expensive to use it extensively. The hardware is optimized for the software that runs on it and vice versa, leaving us stuck in the ghetto of expensive memory management.
If you look at something like the Java Virtual Machine, access control there is very fine-grained, objects can protect their data structures from each other and locking is very easy.
Anybody who has ever done distributed programming should know by now that when one node goes down, often the rest comes down too. It's not always true (but neither is it always true that a crash in a kernel driver would bring the whole system down for a monolithic kernel), but it's true enough if there is any kind of mutual dependencies, and coherency issues.
Failures happen in a lot of way. Sure, "I'm the disk driver and I can't talk to the disk anymore" is a failure that is hard to recover from. However, "I'm the audio driver and I just decided to randomly all over the buffer cache" is could be contained and the driver restarted and the worst you would get is glitchy audio, not corrupted data everywhere.
I think Linus has been working inside the kernel too long. Time to look outside and learn about other things and bring those ideas back.
Individual pieces aren't really any simpler either. In fact, if you want your kernel to scale, to work well with lots of processes, you are going to run into a simple problem: multitasking. This is very true.
Consider a filesystem driver in a monolithic kernel. If a dozen or so processes are all doing filesystem calls, then, assuming proper locking and in-kernel pre-emption, there's no problem - each process that executes the call enters kernel mode and starts executing the relevant kernel code immediately.
OK, here's where things start getting a little tricky. The whole locking setup in a monolithic kernel is pretty tricky. Early multi-processor kernels often took the course of "one big lock" at the top of the call stack - essentially only one process could be executing in the kernel. Why? Because all that "proper locking" is tricky. Took years to get this working right. Of course it's done now in Linux so you can take advantage of it, but it wasn't easy.
Now consider a microkernel. The filesystem driver is a separate server process. Executing a system call means sending a message to that server and waiting for an answer.
OK, now here, you're kind of running off the rails. What is a "message"? There is no magical processor construct called a "message" - it's something that the OS provides. How messages are implemented can vary quite a bit. What you're thinking of is a messaging system ala sockets - that is the message would be placed onto a queue and then a process switch would happen sometime and the server on the other end would read messages out of the queue and do something. That's how microkernels are usually presented conceptually so it tends to get stuck in peoples' heads.
However, messages can be implemented in other ways. For example, you could make a message be more like a procedure call - you create a new stack, swap your address table around, and then jump into the function in the "server". No need to instantiate threads in the "server" anymore than there is a need to instantiate threads within a monolithic kernel. The server would essentially share the thread of the caller. I've worked on microkernel architectures that were implemented just this way.
If the number of data structures that you can directly access is smaller, the amount of locking that you have to take into account is smaller. Modularity and protection makes most people's tasks easier.
Many of the arguments made for monolithic kernels are similar to the arguments you used to hear from Mac programmers who didn't want to admit that protected memory and multi-tasking were good things. Mac programmers liked to (as I used to say) "look in each other's underware". Programs rummaged about through system data structures and other apps data structures sometimes, changing things where they felt like it. This can be pretty fun sometimes and you can do some really spiffy things. However, set one byte the wrong way and the whole system comes crashing down.
Manufacturing hasn't been in Cupertino since the Apple ][ days. I think the original Mac factory was in Sacramento. When I was at Apple in the mid-90's I recall us selling off the factory in Fountain Valley (Southern California) to an outsourcer. The PowerBook 100 was manufactured by Sony if I recall correctly. So, Steve hasn't been able to drive his golf cart over to manufacturing for a damn long time.
Who's raising money? You don't need to. The factory and the suppliers give you credit. You don't need to put any money into R&D (or at least not much) and you're not putting any money into branding or advertising.
You're not selling in the US. There's no threat of lawsuits really. Maybe, possibly, the goods might get confiscated but the odds are highly against it.
It's an easy way to make a buck and it's been going on in the Far East for at least the last 50 years. Counterfeit products are big business. The people buying them usually know they're fake (hey, want a Rolex for $50? If you don't know that it's either fake or stolen you're an idiot). People buy fake iPods because they're half the price so they can afford them but they want something that looks like the real thing not Joe Blow's MP3 player. It's all about the image.
Your second example, of the legitimate company, is absolutely laughable. Have you seen Apple's profits lately?
Yah, Apple's doing great in the MP3 market. Have you seen everybody else's financials? If it's not an iPod your chances of selling an MP3 player are pretty low.
char * data = mmap(0, fileLen, PROT_READ, MAP_FILE, fd, 0);
zero_write(fd2, data, fileLen);
No kernel/user space transitions, no buffer reuse, no malloc/frees (and no way to stop it in the middle of the xfer either:-)). I would wager that *this* is what zero_write is designed for. The code is considerably simpler than trying to manage buffers and get acks back when the buffer is ready to be reused, etc. Most apps don't really generate large amounts of data to be sent over the wire - they're getting it out of files that already exist. The one exception is when you're doing something like SSL.
Your analogy is retarded and refutes itself. Radio frequencies and visible light are all part of the electromagnetic spectrum and are carried by photons. Visible light is a *HIGHER* frequency than microwave radiation. Therefore by your reasoning visible light is more dangerous than microwaves.
When I was in junior high, circa 1978, we used 300 baud acoustic coupler modems to dial up to an HP minicomputer with our 3 (three!) rocking teletypes (and I mean teletypes - these printed on rolls of paper). Acoustic couplers were what we used back when it was difficult to hook things up directly with the phone wiring (RJ-11 jacks were still pretty new back then - most phones were hardwire to the wall). Picture a small white box with two round black rubber cuffs. You picked up the handset, dialed (I think these phones actually had rotary dials, too:-) ), listened for the tone and then stuffed the handset into those two cuffs. A few random characters on the paper and then you get a prompt and you're off.
There's a very compelling interest for safe air travel, and in the interest of safety and absence of any guarantee of anonymity, the government requires proof of identity.
Please explain what that compelling interest is. If Osama Bin Laden wants to hijack a jet plane do you think he's going to show up with a driver's license that says "Osama Bin Laden"? ID's are not secure and you'd do much better with some pictures of bad people who are not allowed to fly rather than checking everyone's ID in a perfunctory manner.
Instead the "No Fly" list is a huge burden for everyone involved, expands the scope of government control greatly and has no real benefit.
Not really. Mach by itself is not a very useful OS - it's more like a base for building other OS's on top of. NeXTStep (which became Mac OS X) has always had BSD on top of Mach as the part that provides all of the POSIX API's, filesystems, etc. while Mach is used to manage threads/processes and IPC.
You didn't read what I wrote. If you do the "swap" the official contract is that they will send you the new iMac and then sometime later you're supposed to send the DTK back. It wouldn't surprise me if when it comes time to send it back they'll give the option of not really returning it or purchasing it for $1 or some such. It's a fully functional PC in a nice case and runs Windows or Linux quite well (or so it's claimed). So, if I have a choice between having an iMac or an iMac and the DTK I'll take the pair. I can always find something to do with another PC.
That's what they say in the description of the swap program. If you actually go and click through on the program (which I did since I have a DTK) what they say is that they'll ship you the new iMac and then sometime afterwards you should ship back the old DTK. The "official" agreement said that the DTK continues to be covered by whatever supplemental terms you agreed to when you got the DTK which in the usual case was that you could keep it until the end of 2006.
Frankly I don't know why they would want the DTK's back. They're nothing special or secret hardware-wise.
I'm a Mac developer and I have a DTK. I develop low level system utilities. Anyone who was dumb enough to write code that calls into the BIOS will get a hanky from Apple to blow their nose into. We all knew that Apple was going the EFI route. The dev machines are required to be returned to Apple under the contract we signed with them (though I still suspect that when it is actually time to ship it back they'll go - Naw, just keep it) so there is no installed base with BIOS and absolutely no commitment to supporting the DTK's with future releases of OS X.
"Power tools for power fools". I had a job as a programmer at a strange little shop when I was in college. This was the place that didn't do backups because the disks were mirrored and the machines were fault tolerant (this came right from the top, the president of the company). Oh, and everyone ran as root because it was easier that way. I remember the day that the president, having elbowed one of the operators out of the way, was sitting at a terminal and typed in "rm *" in the directory with all of the key data in it instead of the directory he thought he was in. He hit "CTRL-C" pretty fast and didn't lose too much but the sheer look of horror on his face was just wonderful. We started doing backups shortly thereafter.
Yes and no. Laches might apply if someone already had a patent but had not enforced it. However, the patent process often takes many years and someone might have a patent slowly working its way through the system. Were one to be granted today it would be presumed to be valid and would take a court battle to overturn.
There used to be a requirement that you had to have "reduced to practice" whatever it was that you were patenting. The patent office used to require you to submit a working scale model.
With today's technology a simulation could be used to the same effect. In the case of a 3D chipset, a Verilog model could be required.
Slashdot Mirror
Fundamentally, if you care about scalability, you need locking for managing your resources, regardless of whether you have a microkernel or a monolithic one, because the on-disk data structures are a shared resource.
You need locking if you want to have things run in a multi-threaded way. However, I would argue that it is much easier to design and manage your locking protocols when you (you includes the development team for your server) are the only ones who have to really understand them and use them.
With this, you reduce the chance that code outside of your driver but inside the kernel could write to your driver's address space, which isn't, in practice, a common occurance, because other code generally won't have pointers that go there.
When a pointer can be created from an integer and when you have functions like "strcpy" which will run happily through memory if you don't have a terminating null, you have a lot of chances for other code to overwrite your data structures. What is this "your driver's address space" you speak of? Doesn't exist in a monolithic kernel. You might have pre-allocated a bunch of space for yourself to use, but it all comes out of the common pool(s) and it's all in the same address space.
That's the whole point! Actually, in Java, from the OS's point of view they're all running in the same address space. From the inside the language point of view, each field has its own little address space with access control on it. It's much finer grained than what the processor gives you and it runs a lot faster.
One might recall that in Smalltalk, the granddaddy of object oriented programming languages, there are no function calls - they're called "messages".
In microkernels you constantly have to worry how to share data with other threads as you can't trust them to give even correct pointers!
This is not unique to micro-kernels. A multi-threaded monolithic kernel has the exact same issues, especially when it is running on true multi-processor hardware. This used to be why kernel guys got the big bucks - now there's a bunch of people who do it for free.
Well, as someone who has been involved in the development of both monolithic and micro kernels, I suspect that I do know something about the subject.
Linux, despite being monolithic, has nice layers inside the kernel and clean interfaces too.
I think you missed Linus' point which I agreed with as well. The real thing you want out of a micro-kernel is memory protection between components of the kernel. The rest is just window dressing.
Linux does *not* have that.
Don't confuse run-time separation with interface separation. The latter is a language feature, not a system feature - you could still have a wild pointer and modify private members of any classes directly.
Let's take a look at OOP and *what* your address spaces are doing for you. Now, in a language like C++, the internal structures of an object are only partially protected. As you say, you can go ahead and cast a pointer to an object to a char * and do anything you feel like to it. The memory protection between objects is not enforced fully.
Now, if you look at Java or C#, the runtime is a virtual processor and it keeps you from violating the rules that an object defines on its data structure. The memory protection is *very* fine grained as it is on the field level rather than on the page level. You cannot (repeat cannot) go modifying the internal structures of objects if they are not marked as being accessible to you.
Having spent 10 years as a kernel developer on a day-in, day-out basis, my frame of mind when I stopped doing OS development for a living was very C based. Since then I've spent a lot of time doing OO development and I think that I've broadened my horizons a bit.
When you look at the way micro-kernels are usually conceptually designed, it's from a C/Unix mind set. Separation is done on a "server" basis and the servers export API's. As you try to add more functionality to the server its API starts getting bigger and bigger and uglier and uglier. For example, you might have a file system server. Locking a file would mean adding a call to the API to lock a file. If you try to make something like a "buffer cache server" which all of the file systems could share it's going to have a nasty API and be slow to boot or it won't be able to enforce memory protection well because the conceptual memory protection is being done on a process level.
When you look at this from an OO perspective, what you see is that the objects being dealt with are "servers" and they are too large. They need to be decomposed into their functional pieces and additional objects exposed. A "buffer cache server" would hand out "buffer objects" which had a memory protection level, locks, etc. built in.
Building a kernel that run inside of some protected runtime environment similar to the JVM would enable you to do this. If it were popular enough the features needed to make it really fast would get moved down into the hardware. As it is, I think that the speed of the kernel is kind of a red herring. In general the kernel needs to do fast I/O and fast switching between user tasks and for any other functions the speed probably doesn't matter much. When I was doing kernel development on supercomputers, most supercomputer kernels were single-threaded, even though the machines were multi-processor and things still ran pretty quickly. That's because most supercomputer apps spent very little time in the kernel. I believe this is true for most desktop apps as well. Business and "server" apps tend to spend more time in the kernel, but mostly because they are doing lots of small I/O's.
Unfortunately there's not a lot of room for innovation in the OS arena so we may never see what could be done. That's one of the reasons why I got out of OS development.
And where do you spend most of your time executing in the BeOS kernel? The high-level libraries and the servers I would bet. The micro-kernel is probably implemented in C because C lets you get close to the hardware easier.
The real issue, and it's really fundamental, is the issue of sharing address spaces. Nothing else really matters. Everything else ends up flowing from that fundamental question: do you share the address space with the caller, or put in slightly different terms: can the callee look at and change the callers state as if it were its own (and the other way around)?
This is a good insight.
The fundamental result of access space separation is that you can't share data structures. That means that you can't share locking, it means that you must copy any shared data, and that in turn means that you have a much harder time handling coherency. All your algorithms basically end up being distributed algorithms.
This is not a good insight.
If you look at object-oriented programming, access control on data structures is a basic requirement. This does not turn every algorithm into distributed algorithms and it makes locking termendously easier, not harder (since each object does its own locking).
The problem that one runs into in the hardware is that hardware level access control is not very fine grained and it can be pretty expensive to use it extensively. The hardware is optimized for the software that runs on it and vice versa, leaving us stuck in the ghetto of expensive memory management.
If you look at something like the Java Virtual Machine, access control there is very fine-grained, objects can protect their data structures from each other and locking is very easy.
Anybody who has ever done distributed programming should know by now that when one node goes down, often the rest comes down too. It's not always true (but neither is it always true that a crash in a kernel driver would bring the whole system down for a monolithic kernel), but it's true enough if there is any kind of mutual dependencies, and coherency issues.
Failures happen in a lot of way. Sure, "I'm the disk driver and I can't talk to the disk anymore" is a failure that is hard to recover from. However, "I'm the audio driver and I just decided to randomly all over the buffer cache" is could be contained and the driver restarted and the worst you would get is glitchy audio, not corrupted data everywhere.
I think Linus has been working inside the kernel too long. Time to look outside and learn about other things and bring those ideas back.
Individual pieces aren't really any simpler either. In fact, if you want your kernel to scale, to work well with lots of processes, you are going to run into a simple problem: multitasking.
This is very true.
Consider a filesystem driver in a monolithic kernel. If a dozen or so processes are all doing filesystem calls, then, assuming proper locking and in-kernel pre-emption, there's no problem - each process that executes the call enters kernel mode and starts executing the relevant kernel code immediately.
OK, here's where things start getting a little tricky. The whole locking setup in a monolithic kernel is pretty tricky. Early multi-processor kernels often took the course of "one big lock" at the top of the call stack - essentially only one process could be executing in the kernel. Why? Because all that "proper locking" is tricky. Took years to get this working right. Of course it's done now in Linux so you can take advantage of it, but it wasn't easy.
Now consider a microkernel. The filesystem driver is a separate server process. Executing a system call means sending a message to that server and waiting for an answer.
OK, now here, you're kind of running off the rails. What is a "message"? There is no magical processor construct called a "message" - it's something that the OS provides. How messages are implemented can vary quite a bit. What you're thinking of is a messaging system ala sockets - that is the message would be placed onto a queue and then a process switch would happen sometime and the server on the other end would read messages out of the queue and do something. That's how microkernels are usually presented conceptually so it tends to get stuck in peoples' heads.
However, messages can be implemented in other ways. For example, you could make a message be more like a procedure call - you create a new stack, swap your address table around, and then jump into the function in the "server". No need to instantiate threads in the "server" anymore than there is a need to instantiate threads within a monolithic kernel. The server would essentially share the thread of the caller. I've worked on microkernel architectures that were implemented just this way.
If the number of data structures that you can directly access is smaller, the amount of locking that you have to take into account is smaller. Modularity and protection makes most people's tasks easier.
Many of the arguments made for monolithic kernels are similar to the arguments you used to hear from Mac programmers who didn't want to admit that protected memory and multi-tasking were good things. Mac programmers liked to (as I used to say) "look in each other's underware". Programs rummaged about through system data structures and other apps data structures sometimes, changing things where they felt like it. This can be pretty fun sometimes and you can do some really spiffy things. However, set one byte the wrong way and the whole system comes crashing down.
Manufacturing hasn't been in Cupertino since the Apple ][ days. I think the original Mac factory was in Sacramento. When I was at Apple in the mid-90's I recall us selling off the factory in Fountain Valley (Southern California) to an outsourcer. The PowerBook 100 was manufactured by Sony if I recall correctly. So, Steve hasn't been able to drive his golf cart over to manufacturing for a damn long time.
Who's raising money? You don't need to. The factory and the suppliers give you credit. You don't need to put any money into R&D (or at least not much) and you're not putting any money into branding or advertising.
You're not selling in the US. There's no threat of lawsuits really. Maybe, possibly, the goods might get confiscated but the odds are highly against it.
It's an easy way to make a buck and it's been going on in the Far East for at least the last 50 years. Counterfeit products are big business. The people buying them usually know they're fake (hey, want a Rolex for $50? If you don't know that it's either fake or stolen you're an idiot). People buy fake iPods because they're half the price so they can afford them but they want something that looks like the real thing not Joe Blow's MP3 player. It's all about the image.
Your second example, of the legitimate company, is absolutely laughable. Have you seen Apple's profits lately?
Yah, Apple's doing great in the MP3 market. Have you seen everybody else's financials? If it's not an iPod your chances of selling an MP3 player are pretty low.
Consider a block like this, though:
:-)).
char * data = mmap(0, fileLen, PROT_READ, MAP_FILE, fd, 0);
zero_write(fd2, data, fileLen);
No kernel/user space transitions, no buffer reuse, no malloc/frees (and no way to stop it in the middle of the xfer either
I would wager that *this* is what zero_write is designed for. The code is considerably simpler than trying to manage buffers and get acks back when the buffer is ready to be reused, etc. Most apps don't really generate large amounts of data to be sent over the wire - they're getting it out of files that already exist. The one exception is when you're doing something like SSL.
Well, either a bug or it only counts up to 128.
You missed the footnote.
I've met have enough computing and storage resources to have themselves classified as large data centers.*
-----------
* A large data center circa 1983
Your analogy is retarded and refutes itself. Radio frequencies and visible light are all part of the electromagnetic spectrum and are carried by photons. Visible light is a *HIGHER* frequency than microwave radiation. Therefore by your reasoning visible light is more dangerous than microwaves.
When I was in junior high, circa 1978, we used 300 baud acoustic coupler modems to dial up to an HP minicomputer with our 3 (three!) rocking teletypes (and I mean teletypes - these printed on rolls of paper). Acoustic couplers were what we used back when it was difficult to hook things up directly with the phone wiring (RJ-11 jacks were still pretty new back then - most phones were hardwire to the wall). Picture a small white box with two round black rubber cuffs. You picked up the handset, dialed (I think these phones actually had rotary dials, too :-) ), listened for the tone and then stuffed the handset into those two cuffs. A few random characters on the paper and then you get a prompt and you're off.
Maximum throughput on given hardware would be constrained by your architecture, not maximum throughput on any hardware.
I've done FS development for 15 years and that article screamed clueless newbie.
There's a very compelling interest for safe air travel, and in the interest of safety and absence of any guarantee of anonymity, the government requires proof of identity.
Please explain what that compelling interest is. If Osama Bin Laden wants to hijack a jet plane do you think he's going to show up with a driver's license that says "Osama Bin Laden"? ID's are not secure and you'd do much better with some pictures of bad people who are not allowed to fly rather than checking everyone's ID in a perfunctory manner.
Instead the "No Fly" list is a huge burden for everyone involved, expands the scope of government control greatly and has no real benefit.
My iBook finished in about 1/2 second. The answer left a bit to be desired, though: "Infinity"
Not really. Mach by itself is not a very useful OS - it's more like a base for building other OS's on top of. NeXTStep (which became Mac OS X) has always had BSD on top of Mach as the part that provides all of the POSIX API's, filesystems, etc. while Mach is used to manage threads/processes and IPC.
You didn't read what I wrote. If you do the "swap" the official contract is that they will send you the new iMac and then sometime later you're supposed to send the DTK back. It wouldn't surprise me if when it comes time to send it back they'll give the option of not really returning it or purchasing it for $1 or some such. It's a fully functional PC in a nice case and runs Windows or Linux quite well (or so it's claimed). So, if I have a choice between having an iMac or an iMac and the DTK I'll take the pair. I can always find something to do with another PC.
That's what they say in the description of the swap program. If you actually go and click through on the program (which I did since I have a DTK) what they say is that they'll ship you the new iMac and then sometime afterwards you should ship back the old DTK. The "official" agreement said that the DTK continues to be covered by whatever supplemental terms you agreed to when you got the DTK which in the usual case was that you could keep it until the end of 2006.
Frankly I don't know why they would want the DTK's back. They're nothing special or secret hardware-wise.
I'm a Mac developer and I have a DTK. I develop low level system utilities. Anyone who was dumb enough to write code that calls into the BIOS will get a hanky from Apple to blow their nose into. We all knew that Apple was going the EFI route. The dev machines are required to be returned to Apple under the contract we signed with them (though I still suspect that when it is actually time to ship it back they'll go - Naw, just keep it) so there is no installed base with BIOS and absolutely no commitment to supporting the DTK's with future releases of OS X.
"Power tools for power fools". I had a job as a programmer at a strange little shop when I was in college. This was the place that didn't do backups because the disks were mirrored and the machines were fault tolerant (this came right from the top, the president of the company). Oh, and everyone ran as root because it was easier that way. I remember the day that the president, having elbowed one of the operators out of the way, was sitting at a terminal and typed in "rm *" in the directory with all of the key data in it instead of the directory he thought he was in. He hit "CTRL-C" pretty fast and didn't lose too much but the sheer look of horror on his face was just wonderful. We started doing backups shortly thereafter.
And they would just kindly replace his broken badge for him unless he had a hissy fit about the RFID tag. So what's the point?
Yes and no. Laches might apply if someone already had a patent but had not enforced it. However, the patent process often takes many years and someone might have a patent slowly working its way through the system. Were one to be granted today it would be presumed to be valid and would take a court battle to overturn.
There used to be a requirement that you had to have "reduced to practice" whatever it was that you were patenting. The patent office used to require you to submit a working scale model.
With today's technology a simulation could be used to the same effect. In the case of a 3D chipset, a Verilog model could be required.