Looks like it makes sort of a symbolic link, though the syntax is backwards: junction . Unfortunatly on my NT5 systems it just says "Cannot create junction for \nThe parameter is incorrect". On Windows2000 it says "The data present in the reparse point buffer is invalid".
It sounds like "junction points" is MicroSoft-code for "symbolic link", with the (harmless imho) limitation that only drives can be linked to. Unfortunately I can't find any readable documentation, what I do find indicates it is at the level of "Explorer" which I already know does not affect how "open()" works. I would like to know what happened to the DOS "assign" command which did do the right thing.
It also sounds like "hard link" is the same as Unix "hard link" which are actually a big mistake in Unix design and are pretty useless. Also the documentation indicates that this exists only in NT 5.0 and later.
Anyway I am still stuck. Does anybody know why Cygwin does not use any of this stuff? I tried Win2K and it is obvious that "ln" just copies the files. Possibly my version is out of date.
Okay, I looked at the page that you pointed at. It clearly states that HFS uses UTF-8 encoding of Unicode characters for the filenames. This means the word "Random" is stored THE SAME for a Japanese user as for an American user, which is not what you were implying. My understanding of your original post is you claimed that it converted encodings. Fortunately Apple is at least smart enough to realize that "encodings" are garbage and have gone with Unicode.
Unfortunatley the document does have definate proof that Apple *IS* stupid. I'm sorry, but it is quite possible for the engineers at Apple to be stupid and they have proven it right there:
This is because they talk about "decompising" characters, which means they want the combined codes in Unicode removed and replaced with the combining accent characters before they store filenames. Their obvious purpose is so that different strings that appear the same to the user will be stored the same. Now the basic cause of this is stupid back-compatability that was put into Unicode where two strings that look identical can be different. However their "solution" is wrong, as wrong as the case-insensitivity "solution".
Decomposing is quite complex and depends on Unicode assignments that have not all been finalized yet. This is extremely bad because some programs are going to rely on algorithims that do not match other programs and fixes to the algorithim (such as adding a new decomposable character) will break existing filesytems. The most likely result is that the code in utfconv.h will be frozen in the filesystem, even if the Unicode consortium changes their rules.
Another indication that they have no idea what they are doing is their failure to realize that this is the same as case insensitivity, but they have failed to put these similar/identical functions in the same place. The decomposing should be done by the *comparing* function, not by the filename storage. This would greatly simplify their code.
I'm sorry but I am completely unimpressed by this document. Apple is being stupid, and this crap is going to bite them eventually. It would be nice if they would pay a little attention to history before going off and making fools of themselves, and of you!
If you could please explain how to create a link on NTFS you will save me and everybody I work with a huge amount of work. However I have yet to see any way that works with the implementation of open() used by most programs. Notice also that we need the link to point to NFS mounted disks.
Thank you for your time in helping us to use NT to it's full advantage.
Just because you can type a lot does not mean you know anything.
Different filenames guarantee unique directory entries. This is quite valuable. Of course they can both point at the same location. But the fact is that "create" called with different strings will ALWAYS make a different file, and that is not true with any system that considers any two different byte streams to match.
And I think users think the file " Random" and "Random " are the same, and maybe event the file "rand0m". Yet your brilliant file system thinks they are different!
Face it, this is a user interface issue. It does not belong in the file system!
And I am absolutely shocked that somebody would be so stupid as to think that matching unicode mappings is a good idea. HFS does not do this, you seem to be confusing the fact that the filenames are Unicode and thus 'r' has a unique byte that does not depend on the "locale".
Oh, I see. Obviously they do want "My Document" and "My Document" to be different, since the file system does allow that.
There is absolutley NO reason for case-insensitivity to be in the file system except for back compatability! Trying to make any other argument and you will soon look like a moron.
You want it when you want a secure, reliable, and understandable system.
Files are identified by streams of bytes. The fewer rules you put on the stream of bytes the better because it simplifies algorithims and makes the system more reliable and less likely to have bugs. Unix is pretty good here in that only nul and the slash are handled specially (I suspect systems could be designed where all bytes are allowed, so Unix is not ideal). Windows is much worse as there are about 2 dozen characters handled specially (ie they are illegal) and there are either 48 or 86 characters that are paired and you must know the equivalence of (there is disagreement about which ones are case-matching, which should also indicate why this is a bad idea).
For some reason there is a huge number of stupid people out there who cannot see that a small user interface enhancement does not have to be built into the lowest levels of the operating system. They are picking a trivial user convienece for typing in filenames into a command line program, and insisting that this dictate low-level design, and are apparently blind to the many ways this could easily be accomplished at the application level. They also fail to see that many other user interface enhancements such as matching or ignoring whitespace or spelling correction are just as valid but are not addressed, and in fact made more difficult, by their insistence on this kludge.
The most absurd thing is the repeated claims that this is user friendly. The average user clicks on icons to pick files and would never notice if the system allowed many files with identical names! In fact this only provides a convenience to command-line programs, and if you ask the same people I'm sure they will be the first to say that Linux sucks because of those user-unfriendly command-line programs!
Really stupid troll there, folks. If "installation" was why virus were hard to make for Linux, then Windows virii would use InstallShield or whatever. Obviously they don't.
In reality the ability of a virus to install itself is about equal on both platforms and is trivial. The trick is to get to a position where the virus has the ability to do the installation. Supposedly this is harder on Linux than Windows and this is the real difference.
Automatic update has it's good and bad points. Although it gets bug fixes installed, it also means a great deal more uniformity for the machines that makes virii easier to spread. It is also possible that a virus will disable it or hijack it for it's own purposes, thus leading people to believe they are in better shape than they really are. However these are minor, the big worry about automatic update is it really is a mechanism for MicroSoft (or Apple, or RedHat) to exert final control over your machine and absoutely should not be trusted by anybody. You should be able to easily turn it off, get a list of the updates, and be assurred they are not installed until you have confirmation from other sources that "update x.y.z is ok".
I meant that a "journal" has to be locked when you insert or retrieve something from it.
This can reduce the work provided that the time code needed to retrieve or insert is tiny compared to the code needed to make the changes. It also requires that the code needed to turn a GUI action into a "message" and to turn a "message" into modifications of the data structure is about the same order of magnitude as the code needed to go from the GUI to the data structure directly. Not counting this overhead has been a problem with many message passing systems, in effect the GUI thread is "blocked" for the time it takes to calculate and insert a message, and the calculation thread is "blocked" for the time it takes to interpret a message, and even though they are not synchronized this overhead can add up to more time.
In fact I think this overhead, and the difficulty of programming message-passing, is why there was such a push for multithreaded applications. I think now we are seeing the backlash as people realize that multithreaded is not the end-all solution they thought it was and are trying to find the correct middle ground between parallel processes and mt.
The only way I see to reduce locks is to "batch" journals entries into a block, and allow them to be inserted and retrieved as blocks. Oddly enough though the more work done on this the more it looks like Unix pipes and stream i/o.
Just tried it and Gnome terminal is certianly messed up. That menu item does paste the selection rather than the clipboard. Worse it claims that ^V is a shortcut and in fact ^V means "send a ^V to the program".
I expect you will find that terminal emulators because they cannot do any shortcuts (at least for ctrl+letter shortcuts) are not going to do this. The Windows terminal completely fails in this area too.
gedit, which was built at the same time and concievably by the same people, works fine. The selection is pasted with middle mouse click and ^V puts in the clipboard.
Plan9 tries to address these things, and does it well, I think.
"object orientation" as spouted by most companies is useless unless the objects can actually work with each other. If the calls to the different objects are different then a program that talks to one type of object cannot talk to another, and it is just buzzwords then. You could take *any* system in the last 30 years and claim it is "object oriented" because you likely went through some common code to talk to the system such as the same interrupt was used for all system calls. This does not mean anything.
REAL object orientation means there has to be a limit on the number of "methods" that an object can have. For instance there might be "read", "write", "close", and "open your child named 'this'". This is the approach used by Plan9. If this minimal set is cleverly designed a vast number of interfaces can be handled by a program.
Oddly enough, the original Unix was perhaps the most correctly object-oriented system in the world. It took terminals, tapes (well, somewhat), and files, and put them all under the same interface. Basically all the devices in common use at that time were under a single interface! The problem was that nobody expanded this as new devices were invented, instead new system calls were added. Also the basic design did lack some kind of "open a child named 'this'" call which I think is needed, if it had only had that we might be using the Unix file system interface for everything today.
On an unrelated note, Linux has versions. Versions are not the problem or the solution for the dependencies. In fact people have complained that Linux programmes keep forcing you to download the latest version when an old one would have worked. I have also heard that MicroSoft's attempt to add versions is resulting in the same complaints. In reality nobody has figured out a solution yet. But I think it might be something like the above. Think about it: most programs that require a certain file in the file system will cleanly handle old versions of the file, and will produce legible errors or fix themselves when the file is missing. Imagine if all the services that are shared libraries now were through the above file-system interface!
Do NOT do anything with ANY encoding other than UTF-8. We do not want "wide characters" because it requires every single interface that uses text to be dupliated because back-compatability with the byte interface is needed.
UTF-8 is a brilliant solution to adding Unicode support to existing systems. In fact it may be close to the best support possible for Unicode, even if you ignore back compatablity, since it builds in a crude Huffman-style compression and allows many useful functions like searches to be done with much smaller lookup tables (ie 256 entries), it encodes 32-bit unicode with no weird hacks (ie no "combining characters" that they had to add to UTF-16), and in fact can be extended in obvious ways to encode objects larger than 32 bits if they become necessary.
I strongly encourage the LSB to insist that ALL interfaces be UTF-8. This means that all "wide character" interfaces and all interfaces that require an "encoding", to be specified be depreciated and eliminated ASAP. It also means that all current byte interfaces be made 8-bit clean and redefined as taking UTF-8 (ie I also propose that Ascii interfaces be removed as well, but the names of them reused as UTF-8).
The original poster may have been confusing UTF-8 with ascii or ISO8859-1, too. Just for the record UTF-8 is able to record all Unicode characters up to 31 bits (the 32 bit is somewhat undecided but I recommend that if needed the encoding be extended to record infinitly-long tokens, rather than using the remaining bit as the 32).
I agree. There is a serious problem that all solutions for this rather basic function seem tied into the desktop environments. This also falls directly under things the LSB should be concerned with (so no complaints about this not being a kernel issue, the LFS is also not a kernel issue).
What we need is a command-line program called "open" that will run any file or url or whatever. It does "what a double-click does". Desktops should be required to use this for double clicks. Obviously a lot of data files would be needed to manage how "open" works but for the vast majority of users and programmers this is unimportant. Certainly if I wanted to write my own file system browser it is easier to fork & exec "open" than to parse the KDE.desktop files.
The shameful fact is that both Windows (which calls it "start") and OS/X have this, while the supposed command-line loving Linux people do not have it.
This is a known problem and has been fixed for over 2 years now in GTK and over a year in Qt. It worked correctly in Motif for 10 years or more.
There was a serious problem with a huge number of programmers (including me) who were unaware of there being a seperate standard clipboard other than the SELECTION which was updated by selecting text and pasted by middle-click. This caused many programs that implemented copy/paste actions like ctrl+c to reuse the SELECTION when they should have been using the CLIPBOARD. This is the cause of the problems you are encountering. However you are falling into the same trap with your "solutions", the real solution is to realize that the copy/paste is different than the X selection mechanism, in fact the X mechanism is really a "drag and drop" with the advantage that you can move around the windows before you decide where to drop (just imagine that clicking the middle mouse button is a "drop" and you will see that this is really what it is).
Also the easiest way to get around this in old programs is to middle-click the data into the start of the text field and use ctrl+k to delete to end of line. But your Windows solutions will all work in newer KDE and GTK programs, and have worked in Motif programs like old Netscape for years.
I'm pretty sure the poster is asking about data types other than text. Though some framework is there this is lacking in the Linux desktops. I agree that Windows "object embedding" is pretty useless and for the average user almost always a mistake when it happens.
Although CVS certainly has problems, I have had not trouble with the "lack of transactions". At least the version I use checks for conflicts before checking anything in.
Biggest problems: the inability to rename or mv files.
Second biggest problem: getting around the inability to rename files involves deleting files and it seems it often goes bonkers here. These seem to be bugs like where it insists that a file is in the repository but will not check it in and refuses addempts to add or remove it.
I have also had trouble with their transactions, if it crashes (esp with SourceForge) in the middle it is left "locked" and nobody can do anything. And you can never get rid of a subdirectory.
I would like to see a new system that treats the entire project as a single "file" and allows changes to be tracked not only across the renameing or moving of files, but also the splitting and joining of files and the movement of large blocks from one file to another (this last one may be hard...)
multithreading gui makes sense because if each widget has its own thread you don't need to have one giant message-transpose-loop which has to do the work for all of them
This is what I meant by "storing state in local variables". This may be a useful goal but I think it requires compiler/language support and certainly there is no reason to use anything other than lightweight threads for this, it can be totally cooperative. In my experience with this (I have tried to write systems that worked this way by using setjmp hacks) there are serious problems with the creation and destruction or visibility changes of widgets, and focus navigation cannot be handled locally by widgets. It also tends not to work well for minimal update, in fact many of the Unix programs you complain about have this exact problem in that they were written so one "important" widget (the main display) was managed using local state and incremental update. So in the end I am unconvinced that this is a good idea. However it could be a very good idea with language support.
By "building new data structure" I mean modifying/creating whatever it is that the parallel calculation thread is reading. You cannot change it without a lock. Obviously you can change the parts the other thread does not care about, but by definition they have nothing to do with the calculation!
I would guess that my implementation is pretty much a "journal". The GUI thread updates structures that are not used by the calculation thread. When it thinks something has changed it kills the calculations threads (there are 4 or more of them), waits for them to go idle, and then copies all the changes from the GUI structure to the actual structure, at that time comparing them to see if there really was a change. This is not "really" a journal because the actual changes are not recorded, but I do make a list of what objects have been modified so it does not have to search them all. If there really was a change it also instructs the calculation to destroy cached data so it starts over at the start. I can't believe my situation is unusual: the data is enormous and the calculation takes several minutes and it is extremely difficult to be certain whether the user's modifications have actually changed anything without looking at the current calculation results.
In any case I cannot see any way a journal can avoid locks. Even if the parallel threads read from the journal you have to lock the journal while this is happening.
Sorry, I'm not arguing with you, I agree. What I am saying is the theft of a disk is not a lost sale, then you also must say that the person downloading an illegal copy also does not represent a lost sale either (which I assumme you would agree with).
The end result is that it is impossible to equate downloading illegal copies with theft unless 100% of the people downloading would have bought a copy if they had not downloaded one.
I'm not sure if 64 bits will fix it completely. It is easy to change the vast majority of code with a recompile (unlike Y2K where you had to change the size of an array from 2 to 3 and there was no easy way to detect it). However there is still going to be structures that have 32 bit entries in them.
But actually the true doomsday is not until about 2100, because this is only for *signed* 32-bit integers. If you assumme unsigned then you get twice as long from 1970 before it overflows. You can also do "sliding window" hacks like those proposed for Y2K that will allow code that relies on negative values to work as long as the negative value is not too big.
Another reason that this is not a problem is that the 1-second resolution is increasingly becoming a problem and I expect virtually all uses of time in Unix to be replaced before then with some higher-resolution thing. Hopefully when this is done they will add enough extra bits so there is no overflow problem for many millenia. Probably 64 bits where 65536 is one second would be a good replacement. 64-bit IEEE floating point might also be good, it would allow short time intervals to be accurate to less than Plank time and allow Universe-age time intervals to be represented with a fraction of a second of accuracy, though the fact that addition is not communative might make people not want to use this.
I'm assumming that the store lost a sale to *me*, since I stole a copy and thus no longer need to buy one. If you don't assumme this then the cost of downloading an illegal copy is zero, since you are not allowing the lost sale to be counted.
I think the cost to Adobe is $25 in the case you specify. However I would certainly agree that I should be charged $500 or even more, as a punishment for doing something illegal. In the same way a copyright violator should also be charged more than the $0 cost, again as punishment. If punishment was only equal to cost then everybody would shoplift all items they wanted, even if caught 99% of the time.
I could cause exactly the same damage to Adobe by making a competing product that was better and cheaper and thus depriving them of a sale, but for some reason that is not considered stealing but is actually considered the entire basis for the free market system. Oddly enough the result for Adobe is identical, yet one of these is definately not "stealing". That is why there are copyright laws, if it was "stealing" there would be no need for those laws, because stealing is illegal under different laws.
Even by your definition taking the disk from Virgin is not stealing twice. This implies that if you did not steal the disk, you would have bought TWO of them!
I hope this will point out exactly how illogical your arguments are, but I think it is a hopeless cause.
Slashdot Mirror
The ads are randomly assigned as the pages are generated. Mine shows an ad from Intel.
Oh well, thanks for trying.
It also sounds like "hard link" is the same as Unix "hard link" which are actually a big mistake in Unix design and are pretty useless. Also the documentation indicates that this exists only in NT 5.0 and later.
Anyway I am still stuck. Does anybody know why Cygwin does not use any of this stuff? I tried Win2K and it is obvious that "ln" just copies the files. Possibly my version is out of date.
Unfortunatley the document does have definate proof that Apple *IS* stupid. I'm sorry, but it is quite possible for the engineers at Apple to be stupid and they have proven it right there:
This is because they talk about "decompising" characters, which means they want the combined codes in Unicode removed and replaced with the combining accent characters before they store filenames. Their obvious purpose is so that different strings that appear the same to the user will be stored the same. Now the basic cause of this is stupid back-compatability that was put into Unicode where two strings that look identical can be different. However their "solution" is wrong, as wrong as the case-insensitivity "solution".
Decomposing is quite complex and depends on Unicode assignments that have not all been finalized yet. This is extremely bad because some programs are going to rely on algorithims that do not match other programs and fixes to the algorithim (such as adding a new decomposable character) will break existing filesytems. The most likely result is that the code in utfconv.h will be frozen in the filesystem, even if the Unicode consortium changes their rules.
Another indication that they have no idea what they are doing is their failure to realize that this is the same as case insensitivity, but they have failed to put these similar/identical functions in the same place. The decomposing should be done by the *comparing* function, not by the filename storage. This would greatly simplify their code.
I'm sorry but I am completely unimpressed by this document. Apple is being stupid, and this crap is going to bite them eventually. It would be nice if they would pay a little attention to history before going off and making fools of themselves, and of you!
Thank you for your time in helping us to use NT to it's full advantage.
Different filenames guarantee unique directory entries. This is quite valuable. Of course they can both point at the same location. But the fact is that "create" called with different strings will ALWAYS make a different file, and that is not true with any system that considers any two different byte streams to match.
And I think users think the file " Random" and "Random " are the same, and maybe event the file "rand0m". Yet your brilliant file system thinks they are different!
Face it, this is a user interface issue. It does not belong in the file system!
And I am absolutely shocked that somebody would be so stupid as to think that matching unicode mappings is a good idea. HFS does not do this, you seem to be confusing the fact that the filenames are Unicode and thus 'r' has a unique byte that does not depend on the "locale".
There is absolutley NO reason for case-insensitivity to be in the file system except for back compatability! Trying to make any other argument and you will soon look like a moron.
Files are identified by streams of bytes. The fewer rules you put on the stream of bytes the better because it simplifies algorithims and makes the system more reliable and less likely to have bugs. Unix is pretty good here in that only nul and the slash are handled specially (I suspect systems could be designed where all bytes are allowed, so Unix is not ideal). Windows is much worse as there are about 2 dozen characters handled specially (ie they are illegal) and there are either 48 or 86 characters that are paired and you must know the equivalence of (there is disagreement about which ones are case-matching, which should also indicate why this is a bad idea).
For some reason there is a huge number of stupid people out there who cannot see that a small user interface enhancement does not have to be built into the lowest levels of the operating system. They are picking a trivial user convienece for typing in filenames into a command line program, and insisting that this dictate low-level design, and are apparently blind to the many ways this could easily be accomplished at the application level. They also fail to see that many other user interface enhancements such as matching or ignoring whitespace or spelling correction are just as valid but are not addressed, and in fact made more difficult, by their insistence on this kludge.
The most absurd thing is the repeated claims that this is user friendly. The average user clicks on icons to pick files and would never notice if the system allowed many files with identical names! In fact this only provides a convenience to command-line programs, and if you ask the same people I'm sure they will be the first to say that Linux sucks because of those user-unfriendly command-line programs!
Seriously, I don't even know how to compile the kernel nowadays, and I have used Linux for years.
In reality the ability of a virus to install itself is about equal on both platforms and is trivial. The trick is to get to a position where the virus has the ability to do the installation. Supposedly this is harder on Linux than Windows and this is the real difference.
Automatic update has it's good and bad points. Although it gets bug fixes installed, it also means a great deal more uniformity for the machines that makes virii easier to spread. It is also possible that a virus will disable it or hijack it for it's own purposes, thus leading people to believe they are in better shape than they really are. However these are minor, the big worry about automatic update is it really is a mechanism for MicroSoft (or Apple, or RedHat) to exert final control over your machine and absoutely should not be trusted by anybody. You should be able to easily turn it off, get a list of the updates, and be assurred they are not installed until you have confirmation from other sources that "update x.y.z is ok".
This can reduce the work provided that the time code needed to retrieve or insert is tiny compared to the code needed to make the changes. It also requires that the code needed to turn a GUI action into a "message" and to turn a "message" into modifications of the data structure is about the same order of magnitude as the code needed to go from the GUI to the data structure directly. Not counting this overhead has been a problem with many message passing systems, in effect the GUI thread is "blocked" for the time it takes to calculate and insert a message, and the calculation thread is "blocked" for the time it takes to interpret a message, and even though they are not synchronized this overhead can add up to more time.
In fact I think this overhead, and the difficulty of programming message-passing, is why there was such a push for multithreaded applications. I think now we are seeing the backlash as people realize that multithreaded is not the end-all solution they thought it was and are trying to find the correct middle ground between parallel processes and mt.
The only way I see to reduce locks is to "batch" journals entries into a block, and allow them to be inserted and retrieved as blocks. Oddly enough though the more work done on this the more it looks like Unix pipes and stream i/o.
I expect you will find that terminal emulators because they cannot do any shortcuts (at least for ctrl+letter shortcuts) are not going to do this. The Windows terminal completely fails in this area too.
gedit, which was built at the same time and concievably by the same people, works fine. The selection is pasted with middle mouse click and ^V puts in the clipboard.
"object orientation" as spouted by most companies is useless unless the objects can actually work with each other. If the calls to the different objects are different then a program that talks to one type of object cannot talk to another, and it is just buzzwords then. You could take *any* system in the last 30 years and claim it is "object oriented" because you likely went through some common code to talk to the system such as the same interrupt was used for all system calls. This does not mean anything.
REAL object orientation means there has to be a limit on the number of "methods" that an object can have. For instance there might be "read", "write", "close", and "open your child named 'this'". This is the approach used by Plan9. If this minimal set is cleverly designed a vast number of interfaces can be handled by a program.
Oddly enough, the original Unix was perhaps the most correctly object-oriented system in the world. It took terminals, tapes (well, somewhat), and files, and put them all under the same interface. Basically all the devices in common use at that time were under a single interface! The problem was that nobody expanded this as new devices were invented, instead new system calls were added. Also the basic design did lack some kind of "open a child named 'this'" call which I think is needed, if it had only had that we might be using the Unix file system interface for everything today.
On an unrelated note, Linux has versions. Versions are not the problem or the solution for the dependencies. In fact people have complained that Linux programmes keep forcing you to download the latest version when an old one would have worked. I have also heard that MicroSoft's attempt to add versions is resulting in the same complaints. In reality nobody has figured out a solution yet. But I think it might be something like the above. Think about it: most programs that require a certain file in the file system will cleanly handle old versions of the file, and will produce legible errors or fix themselves when the file is missing. Imagine if all the services that are shared libraries now were through the above file-system interface!
UTF-8 is a brilliant solution to adding Unicode support to existing systems. In fact it may be close to the best support possible for Unicode, even if you ignore back compatablity, since it builds in a crude Huffman-style compression and allows many useful functions like searches to be done with much smaller lookup tables (ie 256 entries), it encodes 32-bit unicode with no weird hacks (ie no "combining characters" that they had to add to UTF-16), and in fact can be extended in obvious ways to encode objects larger than 32 bits if they become necessary.
I strongly encourage the LSB to insist that ALL interfaces be UTF-8. This means that all "wide character" interfaces and all interfaces that require an "encoding", to be specified be depreciated and eliminated ASAP. It also means that all current byte interfaces be made 8-bit clean and redefined as taking UTF-8 (ie I also propose that Ascii interfaces be removed as well, but the names of them reused as UTF-8).
The original poster may have been confusing UTF-8 with ascii or ISO8859-1, too. Just for the record UTF-8 is able to record all Unicode characters up to 31 bits (the 32 bit is somewhat undecided but I recommend that if needed the encoding be extended to record infinitly-long tokens, rather than using the remaining bit as the 32).
What we need is a command-line program called "open" that will run any file or url or whatever. It does "what a double-click does". Desktops should be required to use this for double clicks. Obviously a lot of data files would be needed to manage how "open" works but for the vast majority of users and programmers this is unimportant. Certainly if I wanted to write my own file system browser it is easier to fork & exec "open" than to parse the KDE .desktop files.
The shameful fact is that both Windows (which calls it "start") and OS/X have this, while the supposed command-line loving Linux people do not have it.
There was a serious problem with a huge number of programmers (including me) who were unaware of there being a seperate standard clipboard other than the SELECTION which was updated by selecting text and pasted by middle-click. This caused many programs that implemented copy/paste actions like ctrl+c to reuse the SELECTION when they should have been using the CLIPBOARD. This is the cause of the problems you are encountering. However you are falling into the same trap with your "solutions", the real solution is to realize that the copy/paste is different than the X selection mechanism, in fact the X mechanism is really a "drag and drop" with the advantage that you can move around the windows before you decide where to drop (just imagine that clicking the middle mouse button is a "drop" and you will see that this is really what it is).
Also the easiest way to get around this in old programs is to middle-click the data into the start of the text field and use ctrl+k to delete to end of line. But your Windows solutions will all work in newer KDE and GTK programs, and have worked in Motif programs like old Netscape for years.
I'm pretty sure the poster is asking about data types other than text. Though some framework is there this is lacking in the Linux desktops. I agree that Windows "object embedding" is pretty useless and for the average user almost always a mistake when it happens.
Biggest problems: the inability to rename or mv files.
Second biggest problem: getting around the inability to rename files involves deleting files and it seems it often goes bonkers here. These seem to be bugs like where it insists that a file is in the repository but will not check it in and refuses addempts to add or remove it.
I have also had trouble with their transactions, if it crashes (esp with SourceForge) in the middle it is left "locked" and nobody can do anything. And you can never get rid of a subdirectory.
I would like to see a new system that treats the entire project as a single "file" and allows changes to be tracked not only across the renameing or moving of files, but also the splitting and joining of files and the movement of large blocks from one file to another (this last one may be hard...)
This is what I meant by "storing state in local variables". This may be a useful goal but I think it requires compiler/language support and certainly there is no reason to use anything other than lightweight threads for this, it can be totally cooperative. In my experience with this (I have tried to write systems that worked this way by using setjmp hacks) there are serious problems with the creation and destruction or visibility changes of widgets, and focus navigation cannot be handled locally by widgets. It also tends not to work well for minimal update, in fact many of the Unix programs you complain about have this exact problem in that they were written so one "important" widget (the main display) was managed using local state and incremental update. So in the end I am unconvinced that this is a good idea. However it could be a very good idea with language support.
By "building new data structure" I mean modifying/creating whatever it is that the parallel calculation thread is reading. You cannot change it without a lock. Obviously you can change the parts the other thread does not care about, but by definition they have nothing to do with the calculation!
I would guess that my implementation is pretty much a "journal". The GUI thread updates structures that are not used by the calculation thread. When it thinks something has changed it kills the calculations threads (there are 4 or more of them), waits for them to go idle, and then copies all the changes from the GUI structure to the actual structure, at that time comparing them to see if there really was a change. This is not "really" a journal because the actual changes are not recorded, but I do make a list of what objects have been modified so it does not have to search them all. If there really was a change it also instructs the calculation to destroy cached data so it starts over at the start. I can't believe my situation is unusual: the data is enormous and the calculation takes several minutes and it is extremely difficult to be certain whether the user's modifications have actually changed anything without looking at the current calculation results.
In any case I cannot see any way a journal can avoid locks. Even if the parallel threads read from the journal you have to lock the journal while this is happening.
The end result is that it is impossible to equate downloading illegal copies with theft unless 100% of the people downloading would have bought a copy if they had not downloaded one.
But actually the true doomsday is not until about 2100, because this is only for *signed* 32-bit integers. If you assumme unsigned then you get twice as long from 1970 before it overflows. You can also do "sliding window" hacks like those proposed for Y2K that will allow code that relies on negative values to work as long as the negative value is not too big.
Another reason that this is not a problem is that the 1-second resolution is increasingly becoming a problem and I expect virtually all uses of time in Unix to be replaced before then with some higher-resolution thing. Hopefully when this is done they will add enough extra bits so there is no overflow problem for many millenia. Probably 64 bits where 65536 is one second would be a good replacement. 64-bit IEEE floating point might also be good, it would allow short time intervals to be accurate to less than Plank time and allow Universe-age time intervals to be represented with a fraction of a second of accuracy, though the fact that addition is not communative might make people not want to use this.
I'm assumming that the store lost a sale to *me*, since I stole a copy and thus no longer need to buy one. If you don't assumme this then the cost of downloading an illegal copy is zero, since you are not allowing the lost sale to be counted.
I could cause exactly the same damage to Adobe by making a competing product that was better and cheaper and thus depriving them of a sale, but for some reason that is not considered stealing but is actually considered the entire basis for the free market system. Oddly enough the result for Adobe is identical, yet one of these is definately not "stealing". That is why there are copyright laws, if it was "stealing" there would be no need for those laws, because stealing is illegal under different laws.
Actually the common expressions seem to be "download" and "rip", not "steal".
I hope this will point out exactly how illogical your arguments are, but I think it is a hopeless cause.