No, the FSS has made no such assumption. Copyright covers *copying* and they know that.
If QuickTime/Windows or Emacs/Windows actually contained an entire copy of Windows (so you could run it on machines without Windows) you can be pretty damn certain Microsoft will not be happy and will stop it.
Sources compiled against the API are NOT affected by the GPL. It is sources that are *linked* with GPL code that is the problem, since when you send them to somebody else you are also sending a copy of the linked source.
Everybody is kind of ignoring it, but there are enormous loopholes in the GPL that could be "exploited". Sending somebody a whole lot of source code and telling them to compile it and link it and you could then say the source code is copyrighted and cannot be copied. However in the real world there are problems: first everything you could take advantage of this way is already LGPL or otherwise has exceptions so you could do this anyway. Second you have given the end user your source code and they can look at it, even if you have them sign a contract saying it is illegal.
If you have a patent on some method, that IDE Raid manufacturer is violating your rights whether or not their driver is open-sourced.
You probably meant a copyright, and that you have personally sold your code to the IDE manufacturer (if they stole it from you, they are in just as much of trouble whether or not they open-source the result).
1: Downloading a GPL'd source in C and compiling it against a binary-only LIBC library with supplied source header...
Allowed.
2: Downloading a BSD'd source and compiling it against a GPL'd LIBC library...
Allowed. You can also compile a completely closed-source code against GPL code. Nothing in the GPL stops you from using the code in any way you want. It only affects redistribution of the code.
Better yet-- providing patches to the BSD source so that it better supports the GPL'd library...
Here is the first example where you actually talk about redistribution (if "providing patches" means sending code to others). If the library is GPL than this means your patched source must be GPL. However you can probably get around it by convincing people that your patches make the program "more portable" or "more standard" or otherwise avoid admitting that the changes were for this GPL library. In any case this is entirely contrived, except for "readline" there are no useful libraries that are GPL and not LGPL.
3: Distributing a GPL'd "wrapper" you wrote and emulates proprietary NDIS Windows Networking drivers?
Allowed. You wrote it and it is pretty obvious that it's use is to load closed-source drivers. If you really think you have to, add an "exception" saying that using this to load closed-source drivers does not violate the license. It's your code and you can modify the GPL in any way you want.
4: Distribute a non-GPL'd (non-redistributable) PHP script that plugs into a GPL'd PHP application server? Is this similar to dynamic linking?
Check the license for the PHP appliation server. In most cases this is allowed.
Nonsense. What you are talking about is equivalent to a run-time switch, or perhaps a compile-time option. It is *NOT* similar to having the source code.
Any knowledgable mechanic can modify a Ford car to remove he catalytic converter using normal tools (ie standard-sized bolts, bits of tubing, etc), and by examining the car (or even the manual that Ford prints) they can easily figure out how to remove it. So I would agree with the original poster that the catalytic converter situation is exactly the same as a hardware manufacturer providing source code, and Ford does not seem to get in trouble for it.
I most certainly did buy an nVidia card because of the Linux support. My machine is dual-boot but the choice of graphics card was dictated by it working well under Linux. It is true that nVidia also works better under Windows than other cards, but the difference is not so great and certainly would not have influenced me except for the fact that it *also* works under Linux.
Therefore I definately believe that nVidia's Linux support is responsible for the sales of thousands of additional cards, just like the original poster said.
Since Walmart already sells *BLANK* pc's I doubt people are going out of there way to buy these machines if they just want to run a cracked copy of Windows.
If you want illegal versions of the source code, you can easily find all of IBM's stuff, all of Windows, all of just about anything. So this would serve no purpose.
It is possible (though unlikely) that the GPL is "invalid" or illegal or something.
The problem for anybody then is that this just makes the GPL's exceptions to copyright invalid. The code is then copyright the original authors and now nobody can use it unless they contract with the original authors. Long before anybody else purchase enough rights I would expect a "fixed GPL" (with whatever changes are needed to get around the illegality) to be created and all important GPL contributors to agree to it.
Darl and company think that making the GPL illegal somehow will put the code in the public domain. But this will not happen, because it says that if you make a mistake in a license you lose your copyright. Disney could lose the copyright to their movies if they made a mistake in the license under which they let people watch the DVD! This is NOT going to happen!
You seem to be confused about what is happening. In fact the redistricing *does* balance the districts.
Image a state is 51% Republican and 49% Democrat (and lets assume nobody changes their vote). It is unlikely these are evenly distributed, for instances the cities may be 75% Democrat, while the suburbs 75% Republican. Now if somebody wanted to make Republicans take *all* the representative seats, they would want to slice the state up into whatever weird shapes are necessary so every slice had a piece of city and a piece of suburb and each was 51% Republican and 49% Democrat. Thus Republicans win in every district.
If instead you made as many 100% Republican districts as possible (using equally weird shapes), you would have just less than half left that are 100% Democrat. Therefore you have only slightly more than 51% Republicans in office. This in fact is a fair result, so it certainly is not in the intrests of the redistrictors.
Also note that the minority Democrats can cause trouble. If somebody interested in as many Democrats as possible did the redistricting, they would make as many districts as possible that are 51% Democrat. The leftover Republicans would be crammed into their own 100% Republican district. Notice that except for the Republican district, again there is even division, and that anything less even is worse for the Democrats.
I think the proper scheme is to use a computer to figure out equal-population areas where the total length of all borders is minimized (probably an NP-complete problem, unfortuantely). The percentages in each district for each party would certainly vary.
I did not know the OS9 aliases were a user-space interface. So in fact only Unix has got this right (and only for symbolic links). I'm very glad you mentioned Plan9, that seems to be the way everything should go, and I am still dumbfounded that nobode seems to think the current solutions are wrong.
Do you have any idea how OS/X does "aliases"? It appears that open() works for them.
Also I was wondering whether "aliases" could be made to work on Unix with a few limitations, mostly that if you delete the aliased file and then recreate it, you are not guaranteed the alias sees it. An "alias" would be *both* a hard link and a symbolic link. When an inode is dereferenced, all the remaining links are checked. If they are all "aliases" then they are all changed to have an illegal inode number. Attempts to open the alias will try the inode hard link first, and then if that fails it will use the text as a symbolic link, and if that works and points to something on the same device it will replace the hard link with a reference to the new file.
With this scheme the pointed-to file can be renamed. And it can be deleted and produce the result the user expects (ie nobody can read it anymore). You make the aliases work again by creating the *orignal* name (not the renamed one, which is what OSX does). This could even be considered a feature, not a bug?
The fact that the filenames are stored next to each other does not mean that a linear search has to be done. There are pointers to those filenames stored elsewhere, I belive in a B-tree or some other rather dated structure (the hash patch you are talking about is to replace the B-tree). The filenames have to be stored somewhere, you know.
"Shortcuts" are files filled with text, including the name of the file pointed-to. These are a type of "broken symbolic link" that I was talking about, though even Microsoft does not claim they are symbolic links. Obviously in theory you can write software to read these and follow the links, but code that calls open() and then read() will not get the expected data. Unfortunatlye the "mount points" or whatever also appear to have the same problem, plus it is totally opaque how to fix this. open() just does not work at all.
"Real" symbolic links should be trivial to implement. The actual data is the linked filename plus a flag indicating that this file is a symbolic link (where are all those NTFS attributes, huh? Those should make this REALLY trivial to implement). The trick is that either the kernel or libc is modified so open() will detect this and instead open the linked file. In fact I'm not sure where Linux does these, it may be libc.
NT is not the only people being idiots here. How come that fancy Gnome or KDE VFS is not accessable to my old program that uses open()? I don't want to use a new library for these "new file names". This really is the same problem as NT has with symbolic links, and the people desiging this stuff for Linux should not feel so proud.
I'm also rather suprised that NT copied one of the mistakes of Unix, which are hard links. These are only useful for making atomic rename operations, but you could do that with just an atomic rename call to the system (unforutnatlye NT does not have that, because it fails if the target exists, so you must do two non-atomic calls, first to remove the target and second to rename, this sucks). I believe otherwise hard links are useless and can be replaced with soft links, any persistant hard links are just confusing.
Mac OS/9 "semi-soft links" sound very interesting, but they do need significant changes to Unix file systems. As I understand it they work like a hard link until the linked file is deleted (or perhaps moved to a volume the hard link can't work with), then it reverts to soft-link behavior.
My god, ignorance no longer is just for Unix history here, but for Microsoft history as well.
PC-DOS certainly was written by Microsoft (ok, if you insist, bought by them from another company, but they did own it and modified it a little). IBM paid Microsoft to develop it for the PC. The fact that it came in a box from IBM did not mean IBM developed it. The paint on the outside of the PC was also not developed by IBM, they paid for it, too.
Note that FAT *requires* the short filenames to work (the long filenames are pretty much a table that returns the short filename). Thus you are saying that use of long filenames is disallowed.
You obviously don't know anything about modern Unix systems. Directories have not been sequential lists in a LONG time. Get your head out of the sand. B-trees and lots of other data structures have been used before Mr Bill started working on DOS!
To be honest I think the abilities of NTFS and current Unix files systems are about equal.
And I would very much like to know how to convince stupid Windows to make one of those "symbolic links". I have NEVER seen this work (by "work" I mean that when I call open() and read, I get the contents of the pointed-to file, not gibberish!)
While these formats (ext2fs, etc) might work out OK, they certainly aren't optimized for small hard drives
Nonsense. When ext2fs was developed, hard disks were typically less than 100Mb. The first one I ever installed went on a whopping-big 720Mb hard disk which I paid a premium for. It certainly was designed for devices of approximately this size, very close to the size of current Flash cards.
In my design I have fixed the set of arguments, which I believe will eliminate the need to copy or memory map a portion of the stack. Because they are a small fixed set they can be copied from the stack by the kernel, or passed in registers. By keeping the set as small as possible, and having most of them be things the kernel needs to look at anyway, it seems to me the overhead of this copying is minimized.
The "buffers" do have to be copied or memory mapped. However this is also simplified in that there are only 2, and they are very simply described (pointer+length) and exactly which way the copying has to be done is determined by looking at 2 bits in the message id by the kernel. Since all other systems get exactly the same message id as the kernel, any other system can also make the exact same decisions, at the same speed, so that the contents of the buffers can be sent through communication protocols easily and transparently.
But it's too late for this. UNIX/Linux assumes a vanilla hardware model; even rings of protection, which are in all IA-32 machines, aren't used. Windows is One Big Kernel for competitive reasons. We've lost the chance to fix this.
I don't understand this. It seems to me that it would not be hard to emulate the old api atop this type of kernel, at least for Unix. I intendended that the mapping of the most common Unix calls is simple and intuitive so that users do not feel they are losing speed by running the emulation layer, however even if the interface was completely different, if it was usable as an operating system I have no doubt Unix (or Windows) can be emulated atop it.
Pretty true, but you are neglecting the need to have calls that *don't* return anything, something which file-type i/o does do very well. Mach and COM and Corba complicate things unneccessarily, requiring either shared memory or complex interpretation of the messages in order to get the data moved. I've wondered why things cannot be done much simpler, combining the best features of file i/o (very predictable arguments), with the syncronous nature of most message passing.
Here is my idea for a system interface. All calls to the system have 6 arguments, probably stuck in registers:
ID: an integer identifier for the receiver of the message. Zero means the kernel itself.
MESSAGE: an integer identifier for the message/method. Bit 0 indicates if the WRITE_BUFFER is to be copied/mapped/etc from the caller to the callee. Bit 1 indicates a synchronous call and it should wait for the callee to finish, copy/map/etc a block of data from the callee back to the caller's READ_BUFFER. If these bits are zero then the buffer pointers and lengths are passed unchanged and just serve as an extra 2 pointer-sized arguments.
WRITE_BUFFER, WRITE_BUFFER_LENGTH: a pointer into the caller's memory space, and the length of that buffer. Somehow (in as fast a way as possible) the callee will get a pointer to a copy-on-write duplicate of at least this memory.
READ_BUFFER, READ_BUFFER_LENGTH: a pointer into the caller's memory space, and the length of that buffer. Somehow (in as fast a way as possible) this memory is replaced on return with a copy-on-write duplicate of some data produced by the callee.
The call returns an integer that is big enough to be used as another ID or as a message.
The callee would be asynchronously called (kind of like a Unix signal) with the same MESSAGE and LENGTH arguments. The pointers may have changed and they point to the callee's memory space, and the ID is changed to identify the local name for the connection.
Everything else is built on that. A number of messages are predefined, such as generic read/write and seek, to provide the huge advantages of Unix style file i/o. Some kernel calls are kludges, for instance memory allocation would use the pointers to indicate the memory to allocate or free.
It would seem that such a system would make there be minimal overhead in the message-passing kernel. Also it would make it easy to stream the messages over another communication protocol, something which is very complex in Mach/COM.
That's counting SCO's $200 mail-in rebate. You need the original sales receipt, UPC symbol cut off the box, your birth certificate, and a urine sample.
Actually a more serious question, every other time somebody has analyzed an exploit (on both Windows or Linux) it seems the analysis is able to say "they used the FooBar hole". This is the first time I have seem somebody say "they used an unknown hole".
This either means that:
1. Hackers are better able to hide what they did than before
2. Some improvement in Linux means that you can now detect unknown exploits much better than before, and before now they were all never seen and thus unanalyzed.
3. I have not really been paying attention, and reports of "unknown hole" are more common than I thought.
The solution is to use UTF-8 everywhere, and design a new input method interface that returns UTF-8. "which language" can now be a function of the input method, it can provide the interface to switch it.
I actully think input methods could be done by a trivial interface that returns "delete this many bytes to the left, delete this many bytes to the right, and insert these bytes". As the user manipulated the input method a text editor could obey this, displaying the resulting utf-8. The only interface would be "give me the pending edits for this X timestamp", "give me the pending edits after the user typed this key", and "reset because the user moved the focus"
Slashdot Mirror
No, the FSS has made no such assumption. Copyright covers *copying* and they know that.
If QuickTime/Windows or Emacs/Windows actually contained an entire copy of Windows (so you could run it on machines without Windows) you can be pretty damn certain Microsoft will not be happy and will stop it.
Sources compiled against the API are NOT affected by the GPL. It is sources that are *linked* with GPL code that is the problem, since when you send them to somebody else you are also sending a copy of the linked source.
Everybody is kind of ignoring it, but there are enormous loopholes in the GPL that could be "exploited". Sending somebody a whole lot of source code and telling them to compile it and link it and you could then say the source code is copyrighted and cannot be copied. However in the real world there are problems: first everything you could take advantage of this way is already LGPL or otherwise has exceptions so you could do this anyway. Second you have given the end user your source code and they can look at it, even if you have them sign a contract saying it is illegal.
If you have a patent on some method, that IDE Raid manufacturer is violating your rights whether or not their driver is open-sourced.
You probably meant a copyright, and that you have personally sold your code to the IDE manufacturer (if they stole it from you, they are in just as much of trouble whether or not they open-source the result).
Oh, come on, this is not really that hard:
1: Downloading a GPL'd source in C and compiling it against a binary-only LIBC library with supplied source header...
Allowed.
2: Downloading a BSD'd source and compiling it against a GPL'd LIBC library...
Allowed. You can also compile a completely closed-source code against GPL code. Nothing in the GPL stops you from using the code in any way you want. It only affects redistribution of the code.
Better yet-- providing patches to the BSD source so that it better supports the GPL'd library...
Here is the first example where you actually talk about redistribution (if "providing patches" means sending code to others). If the library is GPL than this means your patched source must be GPL. However you can probably get around it by convincing people that your patches make the program "more portable" or "more standard" or otherwise avoid admitting that the changes were for this GPL library. In any case this is entirely contrived, except for "readline" there are no useful libraries that are GPL and not LGPL.
3: Distributing a GPL'd "wrapper" you wrote and emulates proprietary NDIS Windows Networking drivers?
Allowed. You wrote it and it is pretty obvious that it's use is to load closed-source drivers. If you really think you have to, add an "exception" saying that using this to load closed-source drivers does not violate the license. It's your code and you can modify the GPL in any way you want.
4: Distribute a non-GPL'd (non-redistributable) PHP script that plugs into a GPL'd PHP application server? Is this similar to dynamic linking?
Check the license for the PHP appliation server. In most cases this is allowed.
Nonsense. What you are talking about is equivalent to a run-time switch, or perhaps a compile-time option. It is *NOT* similar to having the source code.
Any knowledgable mechanic can modify a Ford car to remove he catalytic converter using normal tools (ie standard-sized bolts, bits of tubing, etc), and by examining the car (or even the manual that Ford prints) they can easily figure out how to remove it. So I would agree with the original poster that the catalytic converter situation is exactly the same as a hardware manufacturer providing source code, and Ford does not seem to get in trouble for it.
MESA is open source, was written years ago, and is demonstratably faster than any software-only OpenGL implementation written by SGI or Microsoft.
I most certainly did buy an nVidia card because of the Linux support. My machine is dual-boot but the choice of graphics card was dictated by it working well under Linux. It is true that nVidia also works better under Windows than other cards, but the difference is not so great and certainly would not have influenced me except for the fact that it *also* works under Linux.
Therefore I definately believe that nVidia's Linux support is responsible for the sales of thousands of additional cards, just like the original poster said.
Since Walmart already sells *BLANK* pc's I doubt people are going out of there way to buy these machines if they just want to run a cracked copy of Windows.
The paper is put into a ballot box at the polling place.
It is not taken away by the voter, and thus cannot be used to show how they voted.
Have you even been reading any of the comments here?
That would be illegal.
If you want illegal versions of the source code, you can easily find all of IBM's stuff, all of Windows, all of just about anything. So this would serve no purpose.
It is possible (though unlikely) that the GPL is "invalid" or illegal or something.
The problem for anybody then is that this just makes the GPL's exceptions to copyright invalid. The code is then copyright the original authors and now nobody can use it unless they contract with the original authors. Long before anybody else purchase enough rights I would expect a "fixed GPL" (with whatever changes are needed to get around the illegality) to be created and all important GPL contributors to agree to it.
Darl and company think that making the GPL illegal somehow will put the code in the public domain. But this will not happen, because it says that if you make a mistake in a license you lose your copyright. Disney could lose the copyright to their movies if they made a mistake in the license under which they let people watch the DVD! This is NOT going to happen!
You seem to be confused about what is happening. In fact the redistricing *does* balance the districts.
Image a state is 51% Republican and 49% Democrat (and lets assume nobody changes their vote). It is unlikely these are evenly distributed, for instances the cities may be 75% Democrat, while the suburbs 75% Republican. Now if somebody wanted to make Republicans take *all* the representative seats, they would want to slice the state up into whatever weird shapes are necessary so every slice had a piece of city and a piece of suburb and each was 51% Republican and 49% Democrat. Thus Republicans win in every district.
If instead you made as many 100% Republican districts as possible (using equally weird shapes), you would have just less than half left that are 100% Democrat. Therefore you have only slightly more than 51% Republicans in office. This in fact is a fair result, so it certainly is not in the intrests of the redistrictors.
Also note that the minority Democrats can cause trouble. If somebody interested in as many Democrats as possible did the redistricting, they would make as many districts as possible that are 51% Democrat. The leftover Republicans would be crammed into their own 100% Republican district. Notice that except for the Republican district, again there is even division, and that anything less even is worse for the Democrats.
I think the proper scheme is to use a computer to figure out equal-population areas where the total length of all borders is minimized (probably an NP-complete problem, unfortuantely). The percentages in each district for each party would certainly vary.
Very interesting, thanks!
I did not know the OS9 aliases were a user-space interface. So in fact only Unix has got this right (and only for symbolic links). I'm very glad you mentioned Plan9, that seems to be the way everything should go, and I am still dumbfounded that nobode seems to think the current solutions are wrong.
Do you have any idea how OS/X does "aliases"? It appears that open() works for them.
Also I was wondering whether "aliases" could be made to work on Unix with a few limitations, mostly that if you delete the aliased file and then recreate it, you are not guaranteed the alias sees it. An "alias" would be *both* a hard link and a symbolic link. When an inode is dereferenced, all the remaining links are checked. If they are all "aliases" then they are all changed to have an illegal inode number. Attempts to open the alias will try the inode hard link first, and then if that fails it will use the text as a symbolic link, and if that works and points to something on the same device it will replace the hard link with a reference to the new file.
With this scheme the pointed-to file can be renamed. And it can be deleted and produce the result the user expects (ie nobody can read it anymore). You make the aliases work again by creating the *orignal* name (not the renamed one, which is what OSX does). This could even be considered a feature, not a bug?
The fact that the filenames are stored next to each other does not mean that a linear search has to be done. There are pointers to those filenames stored elsewhere, I belive in a B-tree or some other rather dated structure (the hash patch you are talking about is to replace the B-tree). The filenames have to be stored somewhere, you know.
"Shortcuts" are files filled with text, including the name of the file pointed-to. These are a type of "broken symbolic link" that I was talking about, though even Microsoft does not claim they are symbolic links. Obviously in theory you can write software to read these and follow the links, but code that calls open() and then read() will not get the expected data. Unfortunatlye the "mount points" or whatever also appear to have the same problem, plus it is totally opaque how to fix this. open() just does not work at all.
"Real" symbolic links should be trivial to implement. The actual data is the linked filename plus a flag indicating that this file is a symbolic link (where are all those NTFS attributes, huh? Those should make this REALLY trivial to implement). The trick is that either the kernel or libc is modified so open() will detect this and instead open the linked file. In fact I'm not sure where Linux does these, it may be libc.
NT is not the only people being idiots here. How come that fancy Gnome or KDE VFS is not accessable to my old program that uses open()? I don't want to use a new library for these "new file names". This really is the same problem as NT has with symbolic links, and the people desiging this stuff for Linux should not feel so proud.
I'm also rather suprised that NT copied one of the mistakes of Unix, which are hard links. These are only useful for making atomic rename operations, but you could do that with just an atomic rename call to the system (unforutnatlye NT does not have that, because it fails if the target exists, so you must do two non-atomic calls, first to remove the target and second to rename, this sucks). I believe otherwise hard links are useless and can be replaced with soft links, any persistant hard links are just confusing.
Mac OS/9 "semi-soft links" sound very interesting, but they do need significant changes to Unix file systems. As I understand it they work like a hard link until the linked file is deleted (or perhaps moved to a volume the hard link can't work with), then it reverts to soft-link behavior.
My god, ignorance no longer is just for Unix history here, but for Microsoft history as well.
PC-DOS certainly was written by Microsoft (ok, if you insist, bought by them from another company, but they did own it and modified it a little). IBM paid Microsoft to develop it for the PC. The fact that it came in a box from IBM did not mean IBM developed it. The paint on the outside of the PC was also not developed by IBM, they paid for it, too.
Note that FAT *requires* the short filenames to work (the long filenames are pretty much a table that returns the short filename). Thus you are saying that use of long filenames is disallowed.
You obviously don't know anything about modern Unix systems. Directories have not been sequential lists in a LONG time. Get your head out of the sand. B-trees and lots of other data structures have been used before Mr Bill started working on DOS!
To be honest I think the abilities of NTFS and current Unix files systems are about equal.
And I would very much like to know how to convince stupid Windows to make one of those "symbolic links". I have NEVER seen this work (by "work" I mean that when I call open() and read, I get the contents of the pointed-to file, not gibberish!)
While these formats (ext2fs, etc) might work out OK, they certainly aren't optimized for small hard drives
Nonsense. When ext2fs was developed, hard disks were typically less than 100Mb. The first one I ever installed went on a whopping-big 720Mb hard disk which I paid a premium for. It certainly was designed for devices of approximately this size, very close to the size of current Flash cards.
In my design I have fixed the set of arguments, which I believe will eliminate the need to copy or memory map a portion of the stack. Because they are a small fixed set they can be copied from the stack by the kernel, or passed in registers. By keeping the set as small as possible, and having most of them be things the kernel needs to look at anyway, it seems to me the overhead of this copying is minimized.
The "buffers" do have to be copied or memory mapped. However this is also simplified in that there are only 2, and they are very simply described (pointer+length) and exactly which way the copying has to be done is determined by looking at 2 bits in the message id by the kernel. Since all other systems get exactly the same message id as the kernel, any other system can also make the exact same decisions, at the same speed, so that the contents of the buffers can be sent through communication protocols easily and transparently.
But it's too late for this. UNIX/Linux assumes a vanilla hardware model; even rings of protection, which are in all IA-32 machines, aren't used. Windows is One Big Kernel for competitive reasons. We've lost the chance to fix this.
I don't understand this. It seems to me that it would not be hard to emulate the old api atop this type of kernel, at least for Unix. I intendended that the mapping of the most common Unix calls is simple and intuitive so that users do not feel they are losing speed by running the emulation layer, however even if the interface was completely different, if it was usable as an operating system I have no doubt Unix (or Windows) can be emulated atop it.
Pretty true, but you are neglecting the need to have calls that *don't* return anything, something which file-type i/o does do very well. Mach and COM and Corba complicate things unneccessarily, requiring either shared memory or complex interpretation of the messages in order to get the data moved. I've wondered why things cannot be done much simpler, combining the best features of file i/o (very predictable arguments), with the syncronous nature of most message passing.
Here is my idea for a system interface. All calls to the system have 6 arguments, probably stuck in registers:
ID: an integer identifier for the receiver of the message. Zero means the kernel itself.
MESSAGE: an integer identifier for the message/method. Bit 0 indicates if the WRITE_BUFFER is to be copied/mapped/etc from the caller to the callee. Bit 1 indicates a synchronous call and it should wait for the callee to finish, copy/map/etc a block of data from the callee back to the caller's READ_BUFFER. If these bits are zero then the buffer pointers and lengths are passed unchanged and just serve as an extra 2 pointer-sized arguments.
WRITE_BUFFER, WRITE_BUFFER_LENGTH: a pointer into the caller's memory space, and the length of that buffer. Somehow (in as fast a way as possible) the callee will get a pointer to a copy-on-write duplicate of at least this memory.
READ_BUFFER, READ_BUFFER_LENGTH: a pointer into the caller's memory space, and the length of that buffer. Somehow (in as fast a way as possible) this memory is replaced on return with a copy-on-write duplicate of some data produced by the callee.
The call returns an integer that is big enough to be used as another ID or as a message.
The callee would be asynchronously called (kind of like a Unix signal) with the same MESSAGE and LENGTH arguments. The pointers may have changed and they point to the callee's memory space, and the ID is changed to identify the local name for the connection.
Everything else is built on that. A number of messages are predefined, such as generic read/write and seek, to provide the huge advantages of Unix style file i/o. Some kernel calls are kludges, for instance memory allocation would use the pointers to indicate the memory to allocate or free.
It would seem that such a system would make there be minimal overhead in the message-passing kernel. Also it would make it easy to stream the messages over another communication protocol, something which is very complex in Mach/COM.
That's counting SCO's $200 mail-in rebate. You need the original sales receipt, UPC symbol cut off the box, your birth certificate, and a urine sample.
When I clicked on an ftp url, Safari launched IE to get it! That was very annoying. How did you get it to recognize ftp at all?
However if it mounted the ftp site on the desktop, I don't think I would ever figure out what was going on, sounds like a stupid idea to me.
That is because, duh, they don't know.
Actually a more serious question, every other time somebody has analyzed an exploit (on both Windows or Linux) it seems the analysis is able to say "they used the FooBar hole". This is the first time I have seem somebody say "they used an unknown hole".
This either means that:
1. Hackers are better able to hide what they did than before
2. Some improvement in Linux means that you can now detect unknown exploits much better than before, and before now they were all never seen and thus unanalyzed.
3. I have not really been paying attention, and reports of "unknown hole" are more common than I thought.
Why that just proves what evil geniuses those programmers at Microsoft are, to have planned that so far in advance!
I18N is still stuck in the "encodings" mess.
The solution is to use UTF-8 everywhere, and design a new input method interface that returns UTF-8. "which language" can now be a function of the input method, it can provide the interface to switch it.
I actully think input methods could be done by a trivial interface that returns "delete this many bytes to the left, delete this many bytes to the right, and insert these bytes". As the user manipulated the input method a text editor could obey this, displaying the resulting utf-8. The only interface would be "give me the pending edits for this X timestamp", "give me the pending edits after the user typed this key", and "reset because the user moved the focus"