Well, that's lovely from a theoretical standpoint, and I look foward to using this new breed - in five years. For now, I can browse the web, code in XEmacs, read and reply to emails, and do a lot of file management tasks using Dragon. It's not 100% perfect, but then neither is a keyboard.
Am I the only person who wishes that, as part of certifying a license, OSI would provide a concise explanation of what it means in practice? Obviously you still need to read the license IF you are going to use it, but in choosing a license for a brand new project it would be useful to have a summary of key features to help decide.
One of the reasons I always use GPL or MIT (depending on context) is that they are well-understood in the community, and so we don't get bogged down in legalese.
Could this be a case of diversity being harmful for the community (but, I'm sure, being beneficial to the initial developers in some way)?
The general feeling from posts I've read (at threshold +2, but none of us has infinite amounts of time; exactly what this is all about) is that this is a bad thing. This seems mostly to be along the lines of "that bloody paperclip" / "Microsoft choosing what I should be doing" / "ultra-targetted advertising".
I think this is all wrong.
Sure, I'll state now: I don't believe that Microsoft, the consumer company, can produce a product that will get this right. However I believe that it's not only a useful development, but ultimately an essential one. People seem to be reacting without thinking things through: using a computer to manage incoming information _in_a_flexible_manner_ is surely a good thing.
No single, default, configuration of this sort of thing is going to work for everyone - but consider. I'm at home, I'm hacking on something interesting - say I'm porting linux to a wristwatch. What do I want to be interrupted by, in deep hack mode? Probably not much - except for emails about low-footprint linux issues, maybe. Without a system managing information flow, I'll do this by leaving My Email Client open on the appropriate mailing list inbox, and refreshing it every so often.
Now I take a break, and read some email. I want to deal with important personal emails first - things from my friends. Currently I do that by opening my Personal inbox in My Email Client, and telling it to sort them in some useful way.
Consider those two tasks when an information management system is running. I'll be notified - not in a big, irritating, manner - when an embedded linux message arrives (perhaps a status icon changes in my editor; perhaps a light goes green in my GNOME panel). When I take a break, I can do so by telling the information manager to let through some personal messages. There's not a huge difference - but it's _integrated_. It can manage information from newsgroups, from emails, from IM, from talk(1), from data mining agents working for me. I don't need to context switch myself to check for useful information about the project I'm working on, and I don't have to configure filtering rules on five different packages to avoid being swamped.
Take it further, as they talked about in the article. I'm driving in my car, and there's an in-car computer. I'm off to visit my mother - so I want a message from her to get through to me, in case she's delayed, or has to go out. I probably don't want my boss to be able to call me. If all calls are directed through my information manager, this can be achieved without great difficulty.
Sure, some companies will take this too far. I can see systems (and yes, Microsoft will probably be one) that will make it difficult for you to tell the information manager what you want - they'll try to automate everything so you don't need to configure it. However there are other companies working on this sort of thing - in fact, this is a part of the MIT Oxygen project, as I understand it. It'll take time, but if this sort of technology becomes available outside the normal computer domain (in cars, in phones, in things that people aren't scared of in the way they're scared of computers), people won't think of it so much as a computer device - and they won't tolerate systems that don't work effectively for them. Either they'll switch to another system, or they'll stop using them altogether - and I don't believe that there'll be any shortage of decent systems for people to turn to.
Yes, there are lots of issues. Yes, it's not simple. That's why it's Research; and Microsoft Research (look at the second word through the pink haze produced by the first) is actually pretty good at this. Sure, Bayesian inference may not be the best way of doing this; but you can't really tell until you try it.
There are two main problems that I see here. Actually, one is only relevant because of the other.
If you standardise short options (-h et al), you've effectively locked them out for programs that don't need them. Okay, so everything should support help and version requests - but not everything has a use for -a to mean 'all', or -r to mean 'recurse'. If I don't need a recursive option, but I have an 'open read-only' option, I can't use -r to select it - the short options become less easy to remember. And there are only a limited number anyway (I'm generally opposed to having -V and -v, for instance, doing different things - it's easy to forget which is which).
The other issue is that of deciding on the list of standard options. This isn't such a big problem if you're standardising on long options - saying that --help, --version, --recursive, --all, --reverse, and so on are standard words to use to identify certain actions/options is fine. I don't think it would really make life any easier (most GNU applications using reasonably standard naming of their long options), because most people prefer to use short options.
Several people have already pointed out that this idea already exists in science fiction literature (the instance I thought of immediately, and which is significantly closer to this patent than some examples, is Moses Kaldor, in Arthur C Clarke's Songs of Distant Earth, talking about the possibility of a simulation of his dead wife that he could talk to). However it strikes me that this may not be enough to be considered prior art.
IANAL, but there is a considerable difference between something saying "We've invented virtual people" and "We've invented a way of having virtual people"; this patent is claiming the latter. It's possible that some of the literature people have been talking about here does actually cover some key details (I have a feeling that Songs of Distant Earth does so indirectly). I'm not positive, however, that it matters.
(I'll repeat at this point: IANAL. Also, my 'analysis' of the two patents in question is hampered by the fact that the USPTO website doesn't appear to contain the details of the claims. However I've checked against the IBM patents website, and I don't think I've missed anything that I should have read, so it should just be down to whether I've understood it or not.)
Most of the prior art cited in the patent is concerned with technical and mechanical solutions to problems in implementing this idea; things like voice-synchronised animation, and developments in human-computer interaction through speech. These don't concern us here.
However the last one, US pat. # 5,730,603 (the snappily-titled "Audiovisual simulation system and method with dynamic intelligent prompts"), seems to me to contain all the supposedly-new ideas of US pat. # 5,946,657 (the ancestral computer program one). The latter appears to me to simply be a development of ideas from the previous one - most of the description appears to simply be a rephrasing of the earlier patent, restricting the situation to deceased relatives, and adding a couple of essentially irrelevant user interface issues ("selecting a deceased relative or friend from among those stored in said storage system to communicate interactively with" can hardly be considered a new invention, and "selecting a special occasion which is prompted by a date in the computer operating system" and issuing a greeting based on it is already available in various PIMs, including Microsoft's if I remember correctly). The only interesting part is the invention of a way of aging video and audio, but I think that's been done as well.
Even if the new patent is valid with respect to the older one, I can't see what it is claiming as a new invention except the idea of interacting with a deceased relative - and that, I'd argue, certainly is covered by prior art in sci-fi literature (certainly, it adds nothing to the ideas in Songs of Distant Earth).
Of course, it's possible that buried within the claims is something genuinely new that I've missed, but I doubt there's anything that's widely applicable. It's also possible that I've totally misread something and am talking rubbish.
As to the issue of whether anyone should bother challenging it now - is that really worthwhile? There are many more objectionable patents that should be tackled first, I'd argue. In any case, it's entirely possible that no one will actually build a system which contravenes this patent before it expires (especially since the patent only covers responsive systems - there's nothing at all about ones that can, in the wonderful phrasing of clinical psychiatry, "spontaneously verbalise", and which would be required for a true simulated personality).
Incidentally, the IBM patent search is considerably better laid out than the USPTO one: the patent in question.
James (Who isn't a lawyer, and isn't even a US citizen, for that matter)
Why do these security holes keep showing up in unixes? Because Unix's security model is poor.
I'd be interested to hear exactly why you think this is true. Applications sit in user space, unable to do anything directly to the underlying system; they run under a given uid/gid with certain permissions to restrict what it is they can do. Sure, it might be nice in some cases to have something more akin to the Java sandbox - but at what performance cost - and what, really, do you gain? There are few security improvements you'd get from that, if any.
Also the API is fraught with problems. Just read through the man pages.... you'll often see stuff like "using this function is not recommended because it is insecure".
In which cases there are alternative ways of doing things. These calls exist for backward compatibility reasons - there are some useful programs out there that you might want to run. If you want to get a warning each time these get used, either check the source for those programs, or check a dynamically linked binary to see whether it calls any of them. Simply because there are calls which are inadvisable to use because they are unsafe does not cast doubt on the entire system - if anything, it reassures about its security-conscious facet.
Slashdot Mirror
Well, that's lovely from a theoretical standpoint, and I look foward to using this new breed - in five years. For now, I can browse the web, code in XEmacs, read and reply to emails, and do a lot of file management tasks using Dragon. It's not 100% perfect, but then neither is a keyboard.
Am I the only person who wishes that, as part of certifying a license, OSI would provide a concise explanation of what it means in practice? Obviously you still need to read the license IF you are going to use it, but in choosing a license for a brand new project it would be useful to have a summary of key features to help decide.
One of the reasons I always use GPL or MIT (depending on context) is that they are well-understood in the community, and so we don't get bogged down in legalese.
Could this be a case of diversity being harmful for the community (but, I'm sure, being beneficial to the initial developers in some way)?
The general feeling from posts I've read (at threshold +2, but none of us has infinite amounts of time; exactly what this is all about) is that this is a bad thing. This seems mostly to be along the lines of "that bloody paperclip" / "Microsoft choosing what I should be doing" / "ultra-targetted advertising".
I think this is all wrong.
Sure, I'll state now: I don't believe that Microsoft, the consumer company, can produce a product that will get this right. However I believe that it's not only a useful development, but ultimately an essential one. People seem to be reacting without thinking things through: using a computer to manage incoming information _in_a_flexible_manner_ is surely a good thing.
No single, default, configuration of this sort of thing is going to work for everyone - but consider. I'm at home, I'm hacking on something interesting - say I'm porting linux to a wristwatch. What do I want to be interrupted by, in deep hack mode? Probably not much - except for emails about low-footprint linux issues, maybe. Without a system managing information flow, I'll do this by leaving My Email Client open on the appropriate mailing list inbox, and refreshing it every so often.
Now I take a break, and read some email. I want to deal with important personal emails first - things from my friends. Currently I do that by opening my Personal inbox in My Email Client, and telling it to sort them in some useful way.
Consider those two tasks when an information management system is running. I'll be notified - not in a big, irritating, manner - when an embedded linux message arrives (perhaps a status icon changes in my editor; perhaps a light goes green in my GNOME panel). When I take a break, I can do so by telling the information manager to let through some personal messages. There's not a huge difference - but it's _integrated_. It can manage information from newsgroups, from emails, from IM, from talk(1), from data mining agents working for me. I don't need to context switch myself to check for useful information about the project I'm working on, and I don't have to configure filtering rules on five different packages to avoid being swamped.
Take it further, as they talked about in the article. I'm driving in my car, and there's an in-car computer. I'm off to visit my mother - so I want a message from her to get through to me, in case she's delayed, or has to go out. I probably don't want my boss to be able to call me. If all calls are directed through my information manager, this can be achieved without great difficulty.
Sure, some companies will take this too far. I can see systems (and yes, Microsoft will probably be one) that will make it difficult for you to tell the information manager what you want - they'll try to automate everything so you don't need to configure it. However there are other companies working on this sort of thing - in fact, this is a part of the MIT Oxygen project, as I understand it. It'll take time, but if this sort of technology becomes available outside the normal computer domain (in cars, in phones, in things that people aren't scared of in the way they're scared of computers), people won't think of it so much as a computer device - and they won't tolerate systems that don't work effectively for them. Either they'll switch to another system, or they'll stop using them altogether - and I don't believe that there'll be any shortage of decent systems for people to turn to.
Yes, there are lots of issues. Yes, it's not simple. That's why it's Research; and Microsoft Research (look at the second word through the pink haze produced by the first) is actually pretty good at this. Sure, Bayesian inference may not be the best way of doing this; but you can't really tell until you try it.
There are two main problems that I see here. Actually, one is only relevant because of the other.
...
If you standardise short options (-h et al), you've effectively locked them out for programs that don't need them. Okay, so everything should support help and version requests - but not everything has a use for -a to mean 'all', or -r to mean 'recurse'. If I don't need a recursive option, but I have an 'open read-only' option, I can't use -r to select it - the short options become less easy to remember. And there are only a limited number anyway (I'm generally opposed to having -V and -v, for instance, doing different things - it's easy to forget which is which).
The other issue is that of deciding on the list of standard options. This isn't such a big problem if you're standardising on long options - saying that --help, --version, --recursive, --all, --reverse, and so on are standard words to use to identify certain actions/options is fine. I don't think it would really make life any easier (most GNU applications using reasonably standard naming of their long options), because most people prefer to use short options.
Just my views
Several people have already pointed out that this idea already exists in science fiction literature (the instance I thought of immediately, and which is significantly closer to this patent than some examples, is Moses Kaldor, in Arthur C Clarke's Songs of Distant Earth, talking about the possibility of a simulation of his dead wife that he could talk to). However it strikes me that this may not be enough to be considered prior art.
IANAL, but there is a considerable difference between something saying "We've invented virtual people" and "We've invented a way of having virtual people"; this patent is claiming the latter. It's possible that some of the literature people have been talking about here does actually cover some key details (I have a feeling that Songs of Distant Earth does so indirectly). I'm not positive, however, that it matters.
(I'll repeat at this point: IANAL. Also, my 'analysis' of the two patents in question is hampered by the fact that the USPTO website doesn't appear to contain the details of the claims. However I've checked against the IBM patents website, and I don't think I've missed anything that I should have read, so it should just be down to whether I've understood it or not.)
Most of the prior art cited in the patent is concerned with technical and mechanical solutions to problems in implementing this idea; things like voice-synchronised animation, and developments in human-computer interaction through speech. These don't concern us here.
However the last one, US pat. # 5,730,603 (the snappily-titled "Audiovisual simulation system and method with dynamic intelligent prompts"), seems to me to contain all the supposedly-new ideas of US pat. # 5,946,657 (the ancestral computer program one). The latter appears to me to simply be a development of ideas from the previous one - most of the description appears to simply be a rephrasing of the earlier patent, restricting the situation to deceased relatives, and adding a couple of essentially irrelevant user interface issues ("selecting a deceased relative or friend from among those stored in said storage system to communicate interactively with" can hardly be considered a new invention, and "selecting a special occasion which is prompted by a date in the computer operating system" and issuing a greeting based on it is already available in various PIMs, including Microsoft's if I remember correctly). The only interesting part is the invention of a way of aging video and audio, but I think that's been done as well.
Even if the new patent is valid with respect to the older one, I can't see what it is claiming as a new invention except the idea of interacting with a deceased relative - and that, I'd argue, certainly is covered by prior art in sci-fi literature (certainly, it adds nothing to the ideas in Songs of Distant Earth).
Of course, it's possible that buried within the claims is something genuinely new that I've missed, but I doubt there's anything that's widely applicable. It's also possible that I've totally misread something and am talking rubbish.
As to the issue of whether anyone should bother challenging it now - is that really worthwhile? There are many more objectionable patents that should be tackled first, I'd argue. In any case, it's entirely possible that no one will actually build a system which contravenes this patent before it expires (especially since the patent only covers responsive systems - there's nothing at all about ones that can, in the wonderful phrasing of clinical psychiatry, "spontaneously verbalise", and which would be required for a true simulated personality).
Incidentally, the IBM patent search is considerably better laid out than the USPTO one: the patent in question.
James
(Who isn't a lawyer, and isn't even a US citizen, for that matter)
Why do these security holes keep showing up in unixes? Because Unix's security model is poor.
I'd be interested to hear exactly why you think this is true. Applications sit in user space, unable to do anything directly to the underlying system; they run under a given uid/gid with certain permissions to restrict what it is they can do. Sure, it might be nice in some cases to have something more akin to the Java sandbox - but at what performance cost - and what, really, do you gain? There are few security improvements you'd get from that, if any.
Also the API is fraught with problems. Just read through the man pages.... you'll often see stuff like "using this function is not recommended because it is insecure".
In which cases there are alternative ways of doing things. These calls exist for backward compatibility reasons - there are some useful programs out there that you might want to run. If you want to get a warning each time these get used, either check the source for those programs, or check a dynamically linked binary to see whether it calls any of them. Simply because there are calls which are inadvisable to use because they are unsafe does not cast doubt on the entire system - if anything, it reassures about its security-conscious facet.