This would identify what portions of Linux are infringing, something SCO has refused to do. You could then argue over whether SCO copied it from Linux, Linux copied from SCO, or both copied from a third party, but at worst only those sections would have to be replaced. If it really is an infringement of SCO's copyrights then it will also identify the person responsible, and SCO can go and sue them, like they should have done if they were really trying to protect their copyright.
From your description, it really sounds like it did fall over from a nearly vertical position. And that is certainly what it looks like from the pictures. It slid off that flat white surface to the right.
The article text kind of implied that it only dropped 3 feet, as though it was horizontal and then the top dropped to the floor. Perhaps they were trying to minimize how bad it sounds.
The first impression of the photo is that the satellite tipped completly over from vertical standing on that white framework on the right. You can see another satellite standing up in that position in the background.
However the description does not match this, it says it fell only three feet, from an apparently horizontal position.
What I can't see is what was holding it up in that position. Was that fixture (the "roll over cart") removed? Or is it hidden behind it, or attached to the "bottom" (now on the right edge) or what? How exactly did the missing 24 bolts not become noticed until it was in this horizontal position?
Just curious for more details. Other people's expensive mistakes are always fascinating!
On those projectors pictured, the shutter rotates more than once per frame. Projectors I'm familiar with have more than one blade and rotate once per frame.
In any case there are usually 48 blinks of light per second (sometimes 72 but I belive that may only be on very old projectors designed to project silent films at 18 fps). The trick is that the same frame is shown in more than one blink.
A light blinking 24 times a second is quite obvious, while 48 times per seconds is approaching the limits of what people can see. This ability to detect blinking is much higher than the ability to detect non-smooth motion, which is why they can get away with fewer different pictures.
In fact most hand-drawn animation is done on "twos" and thus only 12fps. Still projected with 48 blinks of the light.
Copy-on-read memory mapping may have worked. However I would expect at the time they would have done shared read/write memory pages and this would have been a nightmare to emulate on a networked file system.
If stacker modified DOS so that programs that opened and read/wrote files and listed directories would work without change and see these files, then this is the type of solution I am talking about.
The exact method is unimportant. What is important is that the interface for "small files" and for "attributes" and "resources" and whatever be *EXACTLY THE SAME INTERFACE* as for files. Ie open() is used to get all pieces of data.
The main difference is that I think the interface that opens these "resources" MUST be the same interface that opens files. IE if you open the file foo with open("folder/foo") then you must be able to open the resource "bar" in "foo" with open("folder/foo/bar"), and NOT with open_resource(fd,"bar").
I should have added "resource" to the list of evil words like "attribute" and "registry". There should be no distinction of these from files either.
Also I realized I left something off about the "relational database" as symbolic links. There needs to be "backwards links". In theory these could be maintained at user level, but filesystem support would be ideal and probably more efficient. If "L/A" is a symbolic link to "B" then there is a file under B that is a symbolic link to "L". There also need to be queries that list files that satisfy several link queries at once. Otherwise you just have a hierarchial database. My important point was that all files in existence must be identified by a hierachial name that is simply derived from one of the database queries that returns the same one.
"Files" are not a bad idea. It is nice to have an interface of commands that is limited in size and easily serialized (ie open/read/write/seek). If Unix had instead mmap'd files in it's original design there would probably not be transparent access to network file systems or many of the other things we take for granted today. So the design of files was actually a huge win.
1. The primary problem is implementation. Filesystems today are designed to store small numbers of very large files (ie more than 1K in size). Anybody who wants to store "objects" that are smaller than about 1K in size (like if you are implementing a "registry", for instance) is forced to write or use a database program, with needless complexity, to force all this data into a single file, so that it can be stored efficiently. What we need is a design where tiny files (like 4 bytes) can be stored efficiently.
Supposedly ReiserFS addresses this, but it is not clear if it does the necessary level of compression: ideally if you had 100 files with the same 50-bytes name and 1 byte stored in them, all those names would be in the same 50 bytes on the disk.
Sadly NOBODY seems to be trying this, and keep spouting "attributes" and "registry" and "config file". Those are all work-arounds for poor file systems.
All files must have the capability of being a "folder" and having subfiles. Any time anybody says "attributes" this should mean this sort of subfile.
2. The other problem is the blinders so people believe the "filename" is some sort of user-friendly data. This leads to brain-dead ideas like "case independence" and "wide characters" and the fact that certain bytes like "/" and zero are disallowed. This requires programs to cook data in strange ways to use it as indexes into the filesystem. This used to be true of the *data* in old systems, and we know now how horrid that was (only a rudimentary piece of that old stupidity remains in Windows text/binary distinction but I hope newer Windows systems will move that out of the kernel).
The filesystem should identify files with a counted length of bytes, just like the data in the file. In fact "name" should be a subfile of any file, and you rename it by writing a new "name". I don't think this can be solved without fixing existing filesystems.
(for "user friendly" names some form of quoting is going to be necessary. Since Windows has made "\" useless I would use that for quoting. "\0" is a null, "\\" is a backslash, "\/" is a forward slash. Just "/" itself indicates a break between hierarchy levels. For semi-Windows compatability you can also make just "\" followed by an unassigned code also mean a break between hierarchy levels.
3. The other thing that is needed (but could be done atop existing implementations) is to change the model of files. They should be "atomic" in that when you open a file for writing, you get an empty file, and this is invisible to any other program. The file only appears at the moment you close it, and only to programs that then open it for reading (programs with the same name already open continue to see the old file). Current files where you can replace a block in the middle are a special case that only a few programs use, and support can be operating-system dependent (and while you are at it, try making it so you can insert or delete data and not just overwrite).
4. As for "database" this can all be done with symbolic links (which can be implemented atop any file system which efficiently stores identical small blocks of data).
Before you call UTF-8 a "hack" you might want to look up "combining characters" as defined by the UTF-16 spec. A fixed-size encoding is the worng idea and will always evolve to a variable-sized one. UTF-8 can now unambigouously and simply represent all Unicode characters up through 2^31-1, and is now easier to correctly interpret than UTF-16 which can only do up to 2^20-1. Plus the obvious advantage that you don't need two interfaces to every possible service in order to preserve back-compatability.
Converting UTF-8 to UTF-16 or UTF-32 is NOT a solution, as the mapping is not unique (due to errorneous UTF-8 sequences). This can lead to serious security and other bugs where software assummes two different strings represent two different objects. The only correct solution is to define file names and other text id's as an unambigous stream of bits with as few rules as possible (for Unix it chokes on a byte-aligned stream of 8 0 bits and a byte-aligned stream of 8 bits representing '/', this is not ideal, but a lot better than even 8-bit Windows where case-insensitivity and a large number of reserved characters breaks it).
"wide characters" are WRONG and this has been proven over and over again by bone-headed attemts to do I18N on Unix systems. You would think Microsoft would at least observe these mistakes before repeating them. Plan9 and UTF-8 existed at the time they were designing I18N, so they have no excuse for not at least seeing the solution.
As for "?", well somehow Unix has allowed wildcard characters to be placed into filenames for 30 years now, so you would think Microsoft could figure out how to do this. Especially since command-line parsing is done in the program rather than the shell (a good idea, imho) and thus it should be much easier on Windows than on Unix.
The shocking thing for me however is that Windows defenders will always say "using the command line is hard" and then every possible excuse for the stupidity in the Windows file system is excused with "that makes it easier to type a file name". Hint: the only reason to type a file name is because you are using that command line!!!
Circa 1985 there were daisy-wheel printers with proportional-spaced fonts, and there were starting to be dot-matrix printers with such fonts. There were also photo typesetters (using a wheel with negative images of the letters) and also just starting to be rasterizing film typesetters. There were also rasterizing printers such as big expensive Xerox page printers.
Advanced software could already print with these proportional fonts for many years. TEX, Scheme, several newsroom systems, and a good deal of commercial software such as FinalWord could do so.
The big difference is that in 1985 "pagination" for these programs was considered part of printing. You had to print to see how your pages would end up. A big "innovation" was to preview the printing somehow so you could see the page breaks (and word wraps) without wasting paper. This was still a seperate step from editing.
At the same time there was "user friendly" programs like you are talking about (Wordstar) which were fixed-pitch only. Almost 100% of the reason these were fixed-pitch was so they could preview word wrap on a character screen, and preview page breaks on a.5mhz machine. It was not hard to print in proportional space, but very hard to make it user friendly.
Changing the margins to get your school report the right length was an already-old technique. Anybody using the advanced programs knew how to change the font or font size or the line spacing to get similar results.
If the code was written so that character types are abstracted...
That will not work. "abstracting" requires storage for what state the characters are in. When I get a string that says it is a filename I want to use it, not figure out what interface I need for it. By your arguments we can all be using EBCDIC as well as ASCII. Read up a little on UTF-8 before you say even more stupid things.
Right now I cannot use the "ascii versions" to access files that are named with unicode characters, so don't give me any BS about using that. NT could easily be fixed to accept UTF-8 there, and the fact that they don't do this does not make me believe they have any idea what is going on or what is really needed.
The Win32 API could easily have been compatable by making "//??/..../" work without using a new call. It would only be incompatable if somebody had make a zero-length file in the root directory (is this even possible?) and then a directory called "??" below that (again I believe this is impossible). Why do you think they picked such weird wording? Yet they seem intent on requiring all software and libc to be rewritten to use the new API. Either they are totally clueless, or they are purposely trying to make cross-platform compatability impossible. In either case it makes me hesitatte to trust Microsoft to design or implement anything.
What do you want to wait on? Pending file operations?
I want to accept a fd provided by a third party without having to know what produced it. Try writing some real software for a change and you will see what a pita this current situation is. For a company that claims it is "object oriented" they certainly have not shown any indication that they care one bit.
Read the article, you moron. See "Windows 2003 server required"? We are talking about elaborate communication schemes designed to force use of Microsoft products in places that seemingly are completely unrelated to the storage and reading of documents. They are trying to force this down companies throats with lies about what it does.
Technically, all the abilities of this could be had by encrypting the document. The encryption could be done in a completly open way so that the only secret needed to decode it is the password. The encryption can be one-way so that even though you can read a document, you cannot modify to a new copy that can be read with a password, unless you have permission to. Word could also refuse to print or copy the text, which will stop casual theft, without giving false sense of security to PHB's who are too stupid to realize that people can photograph the screen.
Even if Microsoft wanted to destroy interoperability with OpenOffice, that could be done with encryption just like the above, except you don't open the method. This probably makes the security slightly less, but makes it impossible to open with any program other than Word. It still has the advantages over their scheme: simplicity (and thus fewer bugs) and the fact that a central server does not have to be relied on.
This is an elaborate scheme to force purchases of their software everywhere.
Sorry I was a doofus. I thought it was going to popup tooltips using javascript. Instead it was displaying the names in the status bar (which I had turned off).
It still cleared the names instantly on the next mouse move. I just tried it in Konqueror and it works pretty well there and the names stay up. So not sure what the problem is with that.
Because I cannot sell the product and be secret, since the "secret" is obvious by looking at the product.
Just to be specific, the patentable method being used by Nuke is that the Directed Acyclic Graph is edited by dragging the "tails" of the connecting lines between nodes (rather than the usual method of drawing "forward" from tail to head) (this has been used in-house at Digital Domain since December 1993). I would like you to tell me how to sell a product using this without revealing the "secret".
There are also several other things I feel are patentable, but they are also GUI related items. Things that I think can be "secret" (like the algorithim used to blur images at high speed) are certainly being kept secret.
It is quite obvious that a company with enough lawyers and willing to take some risk could patent methods even after observing them directly in our software. They could carefully avoid talking to us and instead threaten other compainies so that the obvious prior usage is not found. It would be extremely useful if there was a safe and inexpensive method of making this illegal.
UTF-8 can (and should) be used to encode Unicode into bytes. Wide character filenames solve nothing and cause unbelievable pain for anybody trying to quickly upgrade 8-bit software. And if you think it makes anything simpler, think again, and read up on "combining characters" (which NT fails to implement correctly, by the way).
I am well aware of this "unified name space" However they do not make it accessable to the FileOpen call that almost all C libraries make open() call, therefore by my definition it is inaccessible. They could easily fix this but they are obviously completely paranoid about back compatability.
And you cannot send a file descriptor returned by open() to WaitForMultipleObjects. Again this could be fixed if they would realize that "fd" *is* a "handle".
The idea is that the non-exclusive patent would be free, rather than the tens of thousands of dollars needed for a real patent. Since it would protect the inventor from having the invention "stolen" by another company, even though it would allow "sharing", it could be considered benificial to use one.
I know for a fact that the time and money needed for a patent makes it impractical for even a 600-employee multi-million dollar company to patent inventions. Keeping it secret is useless: the patentable ideas are quite obvious it you try the software. The situation is really, really bad.
Could somebody elaborate on this, or is this person just karma whoring? I thought MT on NT was actually quite acceptable. They did screw up multi *processing* so that a Unix-style solution where one program calls another is inefficient, but I though multithreading where two processors share all memory pages was done reasonably well.
What NT needs from Posix is the uniform filename space. This could be done by migrating some of the innards "kernel names" to the FileOpen interface so any normal program can use this and access "unions" or whatever they call them. This would get rid of drive letters and allow at least a form of symbolic link, these are by far the biggest defects in NT from my perspective.
They also need to allocate all communication channels from the same pool of "fd" numbers and fix their damn select mechanism so that it accepts all of them (it is ok if they always report ready or never report ready, but it is inexcusable that I need to send different things to different interfaces).
I would also like them to return '/' from all their interfaces that return pathnames, and to make filenames be raw byte streams rather than a piece of the GUI (ie eliminate case-independence and wide-character interfaces) but these are probably hopeless. (and the case-independent disease has now invaded OSX Unix so we are probably doomed)
The same program can run under any X environment without any changes.
The main problem for users is that if you use the "official" development environment for KDE or Gnome, your program will link to dozens of shared libraries. These libraries are not necessarily installed on a machine that is running the other system. Recently this situation has improved and most Linux installations put both in. In the future it is hoped that somebody will actually rewrite X and put advanced graphics into it (about 90% of these shared libraries are for drawing graphics).
The more serious problem (but less annoying to users) is that neither system has standardized exactly how to do some operations. For instance getting an arbitrary URL/file to open (HINT TO KDE/GNOME: make a program called "start", or put the name of the program in an environment variable, or something! Comon, this should not be such a pain in the ass!). In my experience though the lack of these interfaces does not cause programs to crash, and usually the produce a reasonable error message.
If I invent a transistor, I need a huge investment to manufacture them. Thus I need defense against somebody who already has the ability to make such an investment, otherwise they will be able to make my invention, and I won't, and it is guaranteed that my invention will be stolen from me without compensation.
If I invent some software, I have done ALL of the work needed. I need no outside investor. If I am really worried that somebody will steal my idea, I can try to keep it secret. I can also copyright the software and nobody can copy it exactly, they will have to do work to reimplement any ideas, and thus I am at an advantage.
Slashdot Mirror
No.
This would identify what portions of Linux are infringing, something SCO has refused to do. You could then argue over whether SCO copied it from Linux, Linux copied from SCO, or both copied from a third party, but at worst only those sections would have to be replaced. If it really is an infringement of SCO's copyrights then it will also identify the person responsible, and SCO can go and sue them, like they should have done if they were really trying to protect their copyright.
From your description, it really sounds like it did fall over from a nearly vertical position. And that is certainly what it looks like from the pictures. It slid off that flat white surface to the right.
The article text kind of implied that it only dropped 3 feet, as though it was horizontal and then the top dropped to the floor. Perhaps they were trying to minimize how bad it sounds.
The first impression of the photo is that the satellite tipped completly over from vertical standing on that white framework on the right. You can see another satellite standing up in that position in the background.
However the description does not match this, it says it fell only three feet, from an apparently horizontal position.
What I can't see is what was holding it up in that position. Was that fixture (the "roll over cart") removed? Or is it hidden behind it, or attached to the "bottom" (now on the right edge) or what? How exactly did the missing 24 bolts not become noticed until it was in this horizontal position?
Just curious for more details. Other people's expensive mistakes are always fascinating!
On those projectors pictured, the shutter rotates more than once per frame. Projectors I'm familiar with have more than one blade and rotate once per frame.
In any case there are usually 48 blinks of light per second (sometimes 72 but I belive that may only be on very old projectors designed to project silent films at 18 fps). The trick is that the same frame is shown in more than one blink.
A light blinking 24 times a second is quite obvious, while 48 times per seconds is approaching the limits of what people can see. This ability to detect blinking is much higher than the ability to detect non-smooth motion, which is why they can get away with fewer different pictures.
In fact most hand-drawn animation is done on "twos" and thus only 12fps. Still projected with 48 blinks of the light.
Copy-on-read memory mapping may have worked. However I would expect at the time they would have done shared read/write memory pages and this would have been a nightmare to emulate on a networked file system.
If stacker modified DOS so that programs that opened and read/wrote files and listed directories would work without change and see these files, then this is the type of solution I am talking about.
The exact method is unimportant. What is important is that the interface for "small files" and for "attributes" and "resources" and whatever be *EXACTLY THE SAME INTERFACE* as for files. Ie open() is used to get all pieces of data.
The main difference is that I think the interface that opens these "resources" MUST be the same interface that opens files. IE if you open the file foo with open("folder/foo") then you must be able to open the resource "bar" in "foo" with open("folder/foo/bar"), and NOT with open_resource(fd,"bar").
I should have added "resource" to the list of evil words like "attribute" and "registry". There should be no distinction of these from files either.
Also I realized I left something off about the "relational database" as symbolic links. There needs to be "backwards links". In theory these could be maintained at user level, but filesystem support would be ideal and probably more efficient. If "L/A" is a symbolic link to "B" then there is a file under B that is a symbolic link to "L". There also need to be queries that list files that satisfy several link queries at once. Otherwise you just have a hierarchial database. My important point was that all files in existence must be identified by a hierachial name that is simply derived from one of the database queries that returns the same one.
"Files" are not a bad idea. It is nice to have an interface of commands that is limited in size and easily serialized (ie open/read/write/seek). If Unix had instead mmap'd files in it's original design there would probably not be transparent access to network file systems or many of the other things we take for granted today. So the design of files was actually a huge win.
1. The primary problem is implementation. Filesystems today are designed to store small numbers of very large files (ie more than 1K in size). Anybody who wants to store "objects" that are smaller than about 1K in size (like if you are implementing a "registry", for instance) is forced to write or use a database program, with needless complexity, to force all this data into a single file, so that it can be stored efficiently. What we need is a design where tiny files (like 4 bytes) can be stored efficiently.
Supposedly ReiserFS addresses this, but it is not clear if it does the necessary level of compression: ideally if you had 100 files with the same 50-bytes name and 1 byte stored in them, all those names would be in the same 50 bytes on the disk.
Sadly NOBODY seems to be trying this, and keep spouting "attributes" and "registry" and "config file". Those are all work-arounds for poor file systems.
All files must have the capability of being a "folder" and having subfiles. Any time anybody says "attributes" this should mean this sort of subfile.
2. The other problem is the blinders so people believe the "filename" is some sort of user-friendly data. This leads to brain-dead ideas like "case independence" and "wide characters" and the fact that certain bytes like "/" and zero are disallowed. This requires programs to cook data in strange ways to use it as indexes into the filesystem. This used to be true of the *data* in old systems, and we know now how horrid that was (only a rudimentary piece of that old stupidity remains in Windows text/binary distinction but I hope newer Windows systems will move that out of the kernel).
The filesystem should identify files with a counted length of bytes, just like the data in the file. In fact "name" should be a subfile of any file, and you rename it by writing a new "name". I don't think this can be solved without fixing existing filesystems.
(for "user friendly" names some form of quoting is going to be necessary. Since Windows has made "\" useless I would use that for quoting. "\0" is a null, "\\" is a backslash, "\/" is a forward slash. Just "/" itself indicates a break between hierarchy levels. For semi-Windows compatability you can also make just "\" followed by an unassigned code also mean a break between hierarchy levels.
3. The other thing that is needed (but could be done atop existing implementations) is to change the model of files. They should be "atomic" in that when you open a file for writing, you get an empty file, and this is invisible to any other program. The file only appears at the moment you close it, and only to programs that then open it for reading (programs with the same name already open continue to see the old file). Current files where you can replace a block in the middle are a special case that only a few programs use, and support can be operating-system dependent (and while you are at it, try making it so you can insert or delete data and not just overwrite).
4. As for "database" this can all be done with symbolic links (which can be implemented atop any file system which efficiently stores identical small blocks of data).
And in 10 years we will be cheering Microsoft on as they try to fight the Sony+RedHat monopoly conglomerate. Things can change and they will...
Before you call UTF-8 a "hack" you might want to look up "combining characters" as defined by the UTF-16 spec. A fixed-size encoding is the worng idea and will always evolve to a variable-sized one. UTF-8 can now unambigouously and simply represent all Unicode characters up through 2^31-1, and is now easier to correctly interpret than UTF-16 which can only do up to 2^20-1. Plus the obvious advantage that you don't need two interfaces to every possible service in order to preserve back-compatability.
Converting UTF-8 to UTF-16 or UTF-32 is NOT a solution, as the mapping is not unique (due to errorneous UTF-8 sequences). This can lead to serious security and other bugs where software assummes two different strings represent two different objects. The only correct solution is to define file names and other text id's as an unambigous stream of bits with as few rules as possible (for Unix it chokes on a byte-aligned stream of 8 0 bits and a byte-aligned stream of 8 bits representing '/', this is not ideal, but a lot better than even 8-bit Windows where case-insensitivity and a large number of reserved characters breaks it).
"wide characters" are WRONG and this has been proven over and over again by bone-headed attemts to do I18N on Unix systems. You would think Microsoft would at least observe these mistakes before repeating them. Plan9 and UTF-8 existed at the time they were designing I18N, so they have no excuse for not at least seeing the solution.
As for "?", well somehow Unix has allowed wildcard characters to be placed into filenames for 30 years now, so you would think Microsoft could figure out how to do this. Especially since command-line parsing is done in the program rather than the shell (a good idea, imho) and thus it should be much easier on Windows than on Unix.
The shocking thing for me however is that Windows defenders will always say "using the command line is hard" and then every possible excuse for the stupidity in the Windows file system is excused with "that makes it easier to type a file name". Hint: the only reason to type a file name is because you are using that command line!!!
Circa 1985 there were daisy-wheel printers with proportional-spaced fonts, and there were starting to be dot-matrix printers with such fonts. There were also photo typesetters (using a wheel with negative images of the letters) and also just starting to be rasterizing film typesetters. There were also rasterizing printers such as big expensive Xerox page printers.
.5mhz machine. It was not hard to print in proportional space, but very hard to make it user friendly.
Advanced software could already print with these proportional fonts for many years. TEX, Scheme, several newsroom systems, and a good deal of commercial software such as FinalWord could do so.
The big difference is that in 1985 "pagination" for these programs was considered part of printing. You had to print to see how your pages would end up. A big "innovation" was to preview the printing somehow so you could see the page breaks (and word wraps) without wasting paper. This was still a seperate step from editing.
At the same time there was "user friendly" programs like you are talking about (Wordstar) which were fixed-pitch only. Almost 100% of the reason these were fixed-pitch was so they could preview word wrap on a character screen, and preview page breaks on a
Changing the margins to get your school report the right length was an already-old technique. Anybody using the advanced programs knew how to change the font or font size or the line spacing to get similar results.
That will not work. "abstracting" requires storage for what state the characters are in. When I get a string that says it is a filename I want to use it, not figure out what interface I need for it. By your arguments we can all be using EBCDIC as well as ASCII. Read up a little on UTF-8 before you say even more stupid things.
Right now I cannot use the "ascii versions" to access files that are named with unicode characters, so don't give me any BS about using that. NT could easily be fixed to accept UTF-8 there, and the fact that they don't do this does not make me believe they have any idea what is going on or what is really needed.
The Win32 API could easily have been compatable by making "//??/..../" work without using a new call. It would only be incompatable if somebody had make a zero-length file in the root directory (is this even possible?) and then a directory called "??" below that (again I believe this is impossible). Why do you think they picked such weird wording? Yet they seem intent on requiring all software and libc to be rewritten to use the new API. Either they are totally clueless, or they are purposely trying to make cross-platform compatability impossible. In either case it makes me hesitatte to trust Microsoft to design or implement anything.
What do you want to wait on? Pending file operations?
I want to accept a fd provided by a third party without having to know what produced it. Try writing some real software for a change and you will see what a pita this current situation is. For a company that claims it is "object oriented" they certainly have not shown any indication that they care one bit.
Read the article, you moron. See "Windows 2003 server required"? We are talking about elaborate communication schemes designed to force use of Microsoft products in places that seemingly are completely unrelated to the storage and reading of documents. They are trying to force this down companies throats with lies about what it does.
Technically, all the abilities of this could be had by encrypting the document. The encryption could be done in a completly open way so that the only secret needed to decode it is the password. The encryption can be one-way so that even though you can read a document, you cannot modify to a new copy that can be read with a password, unless you have permission to. Word could also refuse to print or copy the text, which will stop casual theft, without giving false sense of security to PHB's who are too stupid to realize that people can photograph the screen.
Even if Microsoft wanted to destroy interoperability with OpenOffice, that could be done with encryption just like the above, except you don't open the method. This probably makes the security slightly less, but makes it impossible to open with any program other than Word. It still has the advantages over their scheme: simplicity (and thus fewer bugs) and the fact that a central server does not have to be relied on.
This is an elaborate scheme to force purchases of their software everywhere.
Sorry I was a doofus. I thought it was going to popup tooltips using javascript. Instead it was displaying the names in the status bar (which I had turned off).
It still cleared the names instantly on the next mouse move. I just tried it in Konqueror and it works pretty well there and the names stay up. So not sure what the problem is with that.
Just to be specific, the patentable method being used by Nuke is that the Directed Acyclic Graph is edited by dragging the "tails" of the connecting lines between nodes (rather than the usual method of drawing "forward" from tail to head) (this has been used in-house at Digital Domain since December 1993). I would like you to tell me how to sell a product using this without revealing the "secret".
There are also several other things I feel are patentable, but they are also GUI related items. Things that I think can be "secret" (like the algorithim used to blur images at high speed) are certainly being kept secret.
It is quite obvious that a company with enough lawyers and willing to take some risk could patent methods even after observing them directly in our software. They could carefully avoid talking to us and instead threaten other compainies so that the obvious prior usage is not found. It would be extremely useful if there was a safe and inexpensive method of making this illegal.
Ok, tell me what I pass to open() (not to some NT-specific call) that will open a file on the floppy without the string starting with "A:".
Wide characters are a mistake. Read up on UTF-8 before you make brain-dead comments again. I am *NOT* talking about eliminating Unicode.
I am well aware of this "unified name space" However they do not make it accessable to the FileOpen call that almost all C libraries make open() call, therefore by my definition it is inaccessible. They could easily fix this but they are obviously completely paranoid about back compatability.
And you cannot send a file descriptor returned by open() to WaitForMultipleObjects. Again this could be fixed if they would realize that "fd" *is* a "handle".
The idea is that the non-exclusive patent would be free, rather than the tens of thousands of dollars needed for a real patent. Since it would protect the inventor from having the invention "stolen" by another company, even though it would allow "sharing", it could be considered benificial to use one.
I know for a fact that the time and money needed for a patent makes it impractical for even a 600-employee multi-million dollar company to patent inventions. Keeping it secret is useless: the patentable ideas are quite obvious it you try the software. The situation is really, really bad.
Could somebody elaborate on this, or is this person just karma whoring? I thought MT on NT was actually quite acceptable. They did screw up multi *processing* so that a Unix-style solution where one program calls another is inefficient, but I though multithreading where two processors share all memory pages was done reasonably well.
What NT needs from Posix is the uniform filename space. This could be done by migrating some of the innards "kernel names" to the FileOpen interface so any normal program can use this and access "unions" or whatever they call them. This would get rid of drive letters and allow at least a form of symbolic link, these are by far the biggest defects in NT from my perspective.
They also need to allocate all communication channels from the same pool of "fd" numbers and fix their damn select mechanism so that it accepts all of them (it is ok if they always report ready or never report ready, but it is inexcusable that I need to send different things to different interfaces).
I would also like them to return '/' from all their interfaces that return pathnames, and to make filenames be raw byte streams rather than a piece of the GUI (ie eliminate case-independence and wide-character interfaces) but these are probably hopeless. (and the case-independent disease has now invaded OSX Unix so we are probably doomed)
A real fork would be nice too.
Didn't work in Safari for me. 1.0 v85
Also that balloon page said "sorry Javascript required"
In both cases I have Safari set to the defaults. Java + javascript enabled, popup blocking turned off.
Yep, due to the extreme innovation of the last 10 years, Grandma can now do what was once only possible for computer gurus. Amazing progress!
Everybody asks, "can my Grandma use it" and it appears it is an unqualified yes!
The same program can run under any X environment without any changes.
The main problem for users is that if you use the "official" development environment for KDE or Gnome, your program will link to dozens of shared libraries. These libraries are not necessarily installed on a machine that is running the other system. Recently this situation has improved and most Linux installations put both in. In the future it is hoped that somebody will actually rewrite X and put advanced graphics into it (about 90% of these shared libraries are for drawing graphics).
The more serious problem (but less annoying to users) is that neither system has standardized exactly how to do some operations. For instance getting an arbitrary URL/file to open (HINT TO KDE/GNOME: make a program called "start", or put the name of the program in an environment variable, or something! Comon, this should not be such a pain in the ass!). In my experience though the lack of these interfaces does not cause programs to crash, and usually the produce a reasonable error message.
Hey stupid, before you troll, you might actually try reading what the "slashbots" are posting. I would say 95% of them are against these patents.
There are already several similar programs. Shake is one, and it did copy ideas from Nuke. That's called competition.
No you have it exactly backwards.
If I invent a transistor, I need a huge investment to manufacture them. Thus I need defense against somebody who already has the ability to make such an investment, otherwise they will be able to make my invention, and I won't, and it is guaranteed that my invention will be stolen from me without compensation.
If I invent some software, I have done ALL of the work needed. I need no outside investor. If I am really worried that somebody will steal my idea, I can try to keep it secret. I can also copyright the software and nobody can copy it exactly, they will have to do work to reimplement any ideas, and thus I am at an advantage.