The problems I had with Objective C, which I used on the NeXT when it first came out:
1. By far the biggest is that the syntax has nothing to do with C. Decide that your C code would be better as an object? You have to rewrite every single call to change "method(object, a,b,c)" to "[object method a b c]". Go the other way? Same thing. Because of this Objective C was dead the moment C++ came out, and no amount of technical arguments either way make any difference.
2. It was blatently obvious that the initial version was slow and had significan overhead for each method call. We are talking about 20 mhz machines here, and the fact is that no matter how well it was written, there was at least one function call more than any normal C code would do (a call to the dispatcher code). This basically meant that nobody in their right mind would use Objective C for anything other than the GUI, which only amplified the problems with the syntax differences mentioned above. The first version also looked up the methods very slowly, especially if they were not implemented by the final class, this was addressed later by making a single whole-world hash table rather than one per class (though this required fixing the linker, I think?)
3. The first versions (every version I used) did not produce an error until runtime if you mistyped a method name. This was, I believe, fixed when they fixed the hashing mechanism. However this did not inspire much confidence in the quality of the compiler.
I'm not in favor of any kind of weighted system like I proposed. Although even that would be better than the current system. What I was trying to point out is that all the people who keep saying that this has something to do with small state's rights are completely misled. It does not matter whether you are in favor or against states rights, the argument that the current system matches them is bogus.
It should be pretty obvious that the current scheme allows California to throw a whole lot (30?) electors toward one party, while a small state can only do 3. California can do the opposite of what 49% of it's population wants, which is more than the population *total* of every single "small" state. It is obvious that under the current scheme large states have far more power than they should, far more than anybody who wants a popular election would want, and even *more* compared to what the "states rights" crowd wants.
The trick with this scheme is that it can be implemented without all the states agreeing. It only requires that enough states to have more than 1/2 the total electoral votes agree. This is basically a hack that avoids the need to change the constitution.
The scheme could be altered to exactly what you want. Just figure out who would have won if every state did proportional representation, and then the agreeing states put all their electoral votes to that candidate. Altering the rules like this may be a very good idea as it may make more states agree to it and get it passed.
This is nonsense, and a misunderstanding of what is wrong with the current system.
Under the current system, the small states have almost zero power. There will always be a larger swing state that really is the power in the election. In the past two elections this was Florida and then Ohio, neither of those is a small state.
What you are getting at might be handled by a weighted popular vote. Each vote from a person in a state could be scaled by state_electors/state_population. This would give the extra weight you think the electoral college is giving small states.
Actually this should reduce the problem with recounts.
In the 2000 election, Gore rather clearly won the popular vote by several hundred thousand (or maybe millions?). The questionable votes in Florida were only on the order of hundreds. Even if you assumme every state had similar sized errors (the others were ignored because they were not 50/50) the error is still about 100 times too small to make any difference in the outcome.
In the 2004 election Bush clearly won the popular vote by the same margin. Yet he could have lost the election if Ohio had gone differently by a change of several tens of thousands of votes. But those tens of thousands of votes are way to small to alter the outcome in a popular vote.
The popular vote would make it much harder to rig elections. If your candidate is going to lose by 500 thousand, you must actually rig 500 thousand fake votes. Under the current system you can pick a state with enough electoral votes with the smallest margin against your candidate, and only rig that state, which is probably 50 or more times smaller number of votes you need to fake.
Actually, that Republican would be encouraged to vote whether they lived in a "blue" state, *or* a "red" state, or *any* state. Their vote would count the same amount no matter what.
Contrast this with the current situation, where their vote does not count for anything if they are in a "blue" or "red" state. If the Republicans are sure to win in that state, it does not matter what that Republican does, if the majority of states will go Democrat there is nothing they can do in that state to change that.
The surrogate pairs were introduced for the People's Republic of China (PRC) mandated in 2000 that computer systems sold in its territory must support GB18030, which required that computer systems intended for sale in the PRC must move beyond the BMP.
The precomposed characters are a problem, but there are only about 500 of them and they were allocated long ago as part of Unicode (this should be obvious by the low index numbers). We would be better off without them except for the first 256 codes which I think should match ISO-8859-1 and also add the Microsoft CP1252 codes for 0x80-0x9f. All other ones require some translation of the character indexes from legacy 8-bit codes, so I would think the translator could easily decompose them as well.
As for size, even straight Chinese has enough spaces, control codes, latin letters and numbers, etc, that it is shorter in UTF-8 than in UTF-16. Besides, arguing about size is pointless, as with any modern compression all possible encodings of Unicode end up the same size.
The smaller size is NOT the reason for UTF-8. The reason for UTF-8 is to avoid duplicate code paths due to the need to support ASCII, which triples the size and complexity of the code (two code paths plus all the if's to decide on the path), and, far worse, discourages anybody from implementing or debugging I18N because 90% of their users will only use the ascii path. Unfortunatly "politically correct" attitudes like yours have done FAR MORE to prevent I18N than any redneck american programmer ever did. If we had started using UTF-8 in 1980's without all this lamentation that we are punishing the third world by making their characters take more bytes, we would be supporting it everywhere, seamlessly, today.
If would be *EASY* for Gimp to implement this, *except for the fact that window managers raise on click!*.
If the window manager did not raise on click, Gimp could easily raise the toolbars itself when you clicked in the document window (and raise the document if wanted, placing it below all the toolbars).
But because of that damn window manager raising the clicked window, this is quite impossible, at least without a very annoying flickering effect, and on X you need to handle a whole lot of race conditions. So instead they added the "transient for" attribute to try to get other windows to raise. As you pointed out, this *still* does not work (for instance it is useless if more than one document window shares a toolbar), and is enormously more complex to program than the simple actions if programs could just raise the windows themselves and assumme they are not raised otherwise.
The fact is that as long as the system does *anything* when you click other than tell the program "they clicked here" there is going to be bad GUI.
Re:/proc on steroids
on
Driving Plan 9
·
· Score: 4, Informative
Linux copied the idea of/proc *from* Plan9, so there is certainly some resemblance!
Despite the limited nature of the copy (somebody else says that Linux version is pretty much read-only, I'm not sure) it shoud be obvious what a big win this is. Suddenly a whole lot of utilities like "ps" do not have to be recompiled to match the kernel. And you can peek into/proc directly, without using a program, and get useful information (such as what files are open or the executable name, I've done both of these plenty of times).
The only other Plan-9 thing that is copied extensively is UTF-8 text encoding. This one is also a HUGE win, as suddendly we don't have to write two streams through all our programs for handiling Unicode and handling "legacy" ascii files, as they are now the same thing, as long as some (very minor) fixes are done to the "legacy" code. Plus UTF-8 seamlessly handled Unicode going past 65536 characters, while the "wide character" solution that Sun and HP and Dec and Microsoft struggled with for 20 years fell apart the moment this happened, by adding "surrogate characters" and thus deleting the *only* advantage it had over UTF-8.
Considering how incredibly useful both of these ideas are, I would certainly like to see a lot more of Plan 9 brought out into the real world. There is a lot there!
Actually Plan 9 does far better than "everything is an object". In Plan 9 everthing is a subclass of a certain base object, called a "file". Programs can assumme a set of useful functions, such as the ability to copy an object, that actually makes this api useful, rather than an academic experiment.
About all that "everything is an object" means is that it wont crash if you send the id for one type of object to an api designed for another type, instead you will get an error. Really the only difference between "everything is an object" and all existing operating systems is that the pool of id's for resources is shared between all types of resources.
There are certainly real usable object-oriented systems where there is a base class, but these then imply that "everything is an x" where x is that base class. And so far none of them have as simple of a base class as the Plan 9 file, or one that can actually be understood and used directly by a programmer rather than having to figure out the subclassing api.
You are right about that, I think. I am force to use Gnome at work and it cannot be set to do this. All my tests indicate that KDE works better.
What is really annoying is that I cannot assumme this because it is never the default. Especially because my software has to work on Windows as well. This bug seriously limits the ability to use multiple windows, the only way to make usable software is to not overlap the windows. The easiest way to do that is just to make a giant window and a "tiled" interface, like all other software has been forced to.
What really makes me mad about it is that the opposite would be trivial. If systems never raised windows, a program that *wants* click-to-top could easily get it by calling raise() on all clicks. So a whole class of useful GUI interaction is outlawed for no reason whatsoever...
Sigh. Almost there. ALMOST... We are so close to recovering the GUI technology that existed in 1985 or so.
Here's the idea: DON'T RAISE THE WINDOW WHEN THE USER CLICKS!!! The window should only raise if the user clicks the title bar or if the program does a raise() function.
This was figured out in 1984 (read the X10 release notes where they removed the automatic raise that was in earlier versions of X). It was then lost in 1990 or so becase Windows did not do this and all the sheep blindly copied them. Since then we have been subject to lots of tiled windows, odd-shaped control panels, and very small display areas, because overlapping windows are quite useless as long as you cannot interact with the underlying ones.
Now you have described some kind of elaborate thing using the scroll wheel, simply because they cannot figure it out:
Actually, whether or not there was election fraud, Bush won the election. Under any plausable scenario which limits the fraud to the counties that are questionable, it would require something like 70% majority in those counties voting for Kerry (the fraud then reports this as 49%), to change the outcome of the election. This is astronomically unlikely when neighboring countines that are very similar in demographics and only differ by not having suspicious results, clearly voted only 49% for Kerry.
Equating "there was election fraud" with "Bush stole the election" is a right-wing piece of propaganda, designed to stop any such investigation. In fact the previous election (much more than the 2000 one) is ideal for investigating such fraud, precisely for the reason that it will not make a difference in outcome even if the worst possible imaginable fraud was detected.
I read both articles and I don't recall seeing anywhere that they would allow anyone access to their findings and research.
Actually this matches the GPL quite well. The GPL does not require you to make the source code publically available. It requires you to supply the source code to whoever you give/sell the program to. Thus there is no reason for the public to be able to see the code if all the parties agree to share only with themselves.
[The GPL also requires you to allow the person receiving the program to modify and redistribute it as they see fit, so they *could* make it publically available if they wanted. It is not clear if that is true here, probably not, so that is a difference]
Okay, I REALLY am stumped as to what you are thinking.
My new theory is that you think "UTF-8" is what I would call UCS-2, which is a 2-byte/character encoding. This would explain your claim that UTF-8 is "restricted to big-endian" which otherwise makes no sense. UCS-2 is what Microsoft originally used, and also what Sun and all the other idiots tried to force on us. I fully agree that UCS-2 is a bad idea!
UTF-8 uses from 1 to 4 *BYTES* per character and is not effected by endianess at all. UTF-8 has ALWAYS encoded every single position in Unicode, including every single one that requires surrogate pairs in UTF-16, and the original spec encoded character indexes up to 0x7fffffff, and that requirement was truncated to the limited range of UTF-16.
UTF-16 can be LOSSLESSLY translated to UTF-8. Therefore it is physically impossible that UTF-16 can provide any more functionality than UTF-8. There are no "glyph pairings" or anything else that can be done in UTF-16 that is "lost" in UTF-8.
The codes 0x800 through 0xffff do take 3 bytes in UTF-8 and only take 2 in UTF-16. However any real Chinese text will have enough spaces, numbers, and control characters (which only take 1 byte in UTF-8) to more than make up for this, and in fact real world texts are always shorter in UTF-8 in all languages. Comparing length is irrelevant anyway, as compression will make all encodings about equal in size.
I'm sorry, but you are the one that is confused. I'm not sure exactly what you are thinking, so I will try to correct this as well as I can:
UTF-8 was *ALWAYS* designed to encode far more than 64k characters. It was originally designed to go up to 0x7fffffff, but was cut down in the official standard at the same time UTF-16 was invented. The character 0x10ffff is encoded using 4 bytes, which happens to be the same length that UTF-16 requires. Here is a chart to make sure we are talking about the same thing:
(damn lameness filter probably means this is unreadable!)
It is possible you are also confused by thinking that UTF-8 uses 6 bytes to do codes greater than 0xffff. This is in fact a problem with UTF-16 and stupid converters that don't understand UTF-16 surrogate pairs. These converters are BROKEN and in fact this is the fault of UTF-16 and stupid programmers, not a problem with UTF-8.
I'm also wondering if perhaps you are confusing UTF-16 with UTF-32 (or UCS-4 which is the same). That is to encode each character as a 4-byte word, which is the only practical way to make all of Unicode have the same number of bits per character. It is true that most processing of characters strings, especially to render them, passes through such a stage, since it is trivial to translate to glyphs. However nobody in their right mind would use that as a storage or transmission format. I also think this is misleading, as "combining characters" and more complex layout rules means that more than one code can really turn into a single glyph, and that we would be much better off if the programmers tried to work with variable-length encoding from the start, so they don't have to change gears so drastically when they suddenly run into variable-length layout rules.
I'm also wondering if perhaps you are confising UTF-8 with "8 bits per character", which obviously cannot store more than 256 characters.
UTF-16 is very misleading since there is a temptation to treat it as though each word is a glyph like UTF-32. This seems to be what you are thinking, and that is wrong. I do find it annoying that you are saying I have a "western bias" when in fact your ideas are the ones that make all the Chinese characters not work!
Despite your naive assumption that something with "16" in it's name is better than something with "8", the facts are that UTF-16 cannot handle as many characters:
UTF-16 as originally designed handles 0xffff characters.
Because that was not enough characters, UTF-16 was modified to have "surrogate pairs". Usually claimed to now handle 0x10ffff characters, but in fact they fail to subtract the surrogate half-characters (0x800). Also this deleted the only plausable claim that UTF-16 is better than UTF-8, in that characters all are the same number of bytes long (it is in fact worse, because the variable-length characters are much more rare, so bugs in handling them are much less likely to be detected and thus more catostrophic when they do happen).
UTF-8 as originally designed handles 0x7fffffff characters.
Because of the UTF-16 braindamage, the standards for UTF-8 were modified to say that all encodings after 0x10ffff are illegal, so literally UTF-8 was downgraded to match UTF-16. It still is false to say that you can losslessly translate from UTF-8 to UTF-16, due to the surrogate pairs, so they are not equivalent even with this limitation.
The one positive benifit of the "Unix wars" was that it stopped a whole lot of politically-correct idiots from forcing "wide characters" on everybody, and thus Plan9's UTF-8 could take hold. Unfortunatly Microsoft completely ignored all the proof that wide characters were a very bad idea and went and did it themselves in Windows. Still not as bad as if Unix had done it too...
The definatly did not alter POSIX, a colon passed to it is part of a filename, and a slash is always a sperator.
The swapping of colon and slash is done by the Carbon emulation.
You are correct that whether a Cocoa system does this depends on whether it calls POSIX or Carbon emulation. But I think almost all of Cocoa uses the POSIX api, as it is based on NeXTStep which was a Unix system.
This is wrong. The quoting is removed long before the filename is passed to the system.
I think you may be confusing it with backslash, which you can put in by doubling it (that will quote it, the quoting is stripped by the shell leaving a single backslash, and that is passed to the system, which treats it like any other character and puts it in the filename). However even with this, backslash is not recommended, since in many cases it will be passed through quoting-stripping more than once, such as when one script calls another and they are not correctly written.
This guy is complaining about the history-substitution in the Unix shells. This problem also exists on Windows if you use tcsh or something.
It is annoying sometimes. Backslash works a lot but I think it is inconsistent. Also I have never used ! except at the start of the line, command-line editing makes all other uses pretty obsolete, so removing this from a shell would probably be useful.
The windows users I know use '@' for the same purpose, oddly enough.
The actual limits were that the extension could not have more than 3 characters, and (more annoyingly) the extension always had to be there. The actual FAT storage had 11 bytes to stash the filename in, and it always stuck a period after the 8th character. The sections could be shorter by filling the unused bytes with null (? or maybe space?).
The filenames "foo" and "foo." were the same file. Programs were somewhat inconsistent as to whether they printed the period or not in this case.
You could actually make files named ".foo" which was convienent for Unix emulation, but only 3 letters. Also some programs crashed on that.
Breaching the lining and knocking out the pumps will flood the tunnel, drowning everybody inside it, and probably putting it out of commission for months or years.
First off, you need to download a few free programs: Windows Media Player (although I'm sure you've got this - it's bundled with every version of Windows since 98), the Nero Fast Burning Plugin (details from wmplugins.com and download from here),...
This process does NOT work with Windows Media Player 10. See the FAQ Page for details.
Another possibility is that you bought the tracks from Napster. If so, Napster charge you extra to allow you to copy the song to a CD, and therefore, you can't remove the DRM using the method shown on my website.
* Backup music files from Napster/other companies that allow CD burning:
* Download the songs from Napster
* Burn the songs to a CD e.g. using Nero
* Rip the CD to MP3 e.g using Easy CDDA Creator
* Convert to any format you like e.g. using again Easy CDDA Creator
Now I am perhaps reading this wrong, but it sure sounds like you need a third party software called "Nero" to burn a CD. It is possible that the purpose of this software is to make a disk image to avoid using a real CD, however not ONCE have I seen anybody say "use WMP to burn a CD". Also it is pretty obvious that the WMA DRM allows a track to be marked as "can't make a CD from this".
A quick google for "wma drm burn cd" will reveal that protected WMA will *NOT* burn to a CD without third-party software. Something called "Nero" seems to be the most-mentioned way to do it.
Listen, I really don't think Microsoft fans are as stupid as you are trying to look. If this is some sort of troll to try to make them look bad, that is pretty shameful.
Slashdot Mirror
The problems I had with Objective C, which I used on the NeXT when it first came out:
1. By far the biggest is that the syntax has nothing to do with C. Decide that your C code would be better as an object? You have to rewrite every single call to change "method(object, a,b,c)" to "[object method a b c]". Go the other way? Same thing. Because of this Objective C was dead the moment C++ came out, and no amount of technical arguments either way make any difference.
2. It was blatently obvious that the initial version was slow and had significan overhead for each method call. We are talking about 20 mhz machines here, and the fact is that no matter how well it was written, there was at least one function call more than any normal C code would do (a call to the dispatcher code). This basically meant that nobody in their right mind would use Objective C for anything other than the GUI, which only amplified the problems with the syntax differences mentioned above. The first version also looked up the methods very slowly, especially if they were not implemented by the final class, this was addressed later by making a single whole-world hash table rather than one per class (though this required fixing the linker, I think?)
3. The first versions (every version I used) did not produce an error until runtime if you mistyped a method name. This was, I believe, fixed when they fixed the hashing mechanism. However this did not inspire much confidence in the quality of the compiler.
Microsoft will not implement real, working symlinks, because that would make it too easy to emulate a Unix setup on Windows.
I'm not in favor of any kind of weighted system like I proposed. Although even that would be better than the current system. What I was trying to point out is that all the people who keep saying that this has something to do with small state's rights are completely misled. It does not matter whether you are in favor or against states rights, the argument that the current system matches them is bogus.
It should be pretty obvious that the current scheme allows California to throw a whole lot (30?) electors toward one party, while a small state can only do 3. California can do the opposite of what 49% of it's population wants, which is more than the population *total* of every single "small" state. It is obvious that under the current scheme large states have far more power than they should, far more than anybody who wants a popular election would want, and even *more* compared to what the "states rights" crowd wants.
The trick with this scheme is that it can be implemented without all the states agreeing. It only requires that enough states to have more than 1/2 the total electoral votes agree. This is basically a hack that avoids the need to change the constitution.
The scheme could be altered to exactly what you want. Just figure out who would have won if every state did proportional representation, and then the agreeing states put all their electoral votes to that candidate. Altering the rules like this may be a very good idea as it may make more states agree to it and get it passed.
This is nonsense, and a misunderstanding of what is wrong with the current system.
Under the current system, the small states have almost zero power. There will always be a larger swing state that really is the power in the election. In the past two elections this was Florida and then Ohio, neither of those is a small state.
What you are getting at might be handled by a weighted popular vote. Each vote from a person in a state could be scaled by state_electors/state_population. This would give the extra weight you think the electoral college is giving small states.
Actually this should reduce the problem with recounts.
In the 2000 election, Gore rather clearly won the popular vote by several hundred thousand (or maybe millions?). The questionable votes in Florida were only on the order of hundreds. Even if you assumme every state had similar sized errors (the others were ignored because they were not 50/50) the error is still about 100 times too small to make any difference in the outcome.
In the 2004 election Bush clearly won the popular vote by the same margin. Yet he could have lost the election if Ohio had gone differently by a change of several tens of thousands of votes. But those tens of thousands of votes are way to small to alter the outcome in a popular vote.
The popular vote would make it much harder to rig elections. If your candidate is going to lose by 500 thousand, you must actually rig 500 thousand fake votes. Under the current system you can pick a state with enough electoral votes with the smallest margin against your candidate, and only rig that state, which is probably 50 or more times smaller number of votes you need to fake.
Actually, that Republican would be encouraged to vote whether they lived in a "blue" state, *or* a "red" state, or *any* state. Their vote would count the same amount no matter what.
Contrast this with the current situation, where their vote does not count for anything if they are in a "blue" or "red" state. If the Republicans are sure to win in that state, it does not matter what that Republican does, if the majority of states will go Democrat there is nothing they can do in that state to change that.
The surrogate pairs were introduced for the People's Republic of China (PRC) mandated in 2000 that computer systems sold in its territory must support GB18030, which required that computer systems intended for sale in the PRC must move beyond the BMP.
The precomposed characters are a problem, but there are only about 500 of them and they were allocated long ago as part of Unicode (this should be obvious by the low index numbers). We would be better off without them except for the first 256 codes which I think should match ISO-8859-1 and also add the Microsoft CP1252 codes for 0x80-0x9f. All other ones require some translation of the character indexes from legacy 8-bit codes, so I would think the translator could easily decompose them as well.
As for size, even straight Chinese has enough spaces, control codes, latin letters and numbers, etc, that it is shorter in UTF-8 than in UTF-16. Besides, arguing about size is pointless, as with any modern compression all possible encodings of Unicode end up the same size.
The smaller size is NOT the reason for UTF-8. The reason for UTF-8 is to avoid duplicate code paths due to the need to support ASCII, which triples the size and complexity of the code (two code paths plus all the if's to decide on the path), and, far worse, discourages anybody from implementing or debugging I18N because 90% of their users will only use the ascii path. Unfortunatly "politically correct" attitudes like yours have done FAR MORE to prevent I18N than any redneck american programmer ever did. If we had started using UTF-8 in 1980's without all this lamentation that we are punishing the third world by making their characters take more bytes, we would be supporting it everywhere, seamlessly, today.
If would be *EASY* for Gimp to implement this, *except for the fact that window managers raise on click!*.
If the window manager did not raise on click, Gimp could easily raise the toolbars itself when you clicked in the document window (and raise the document if wanted, placing it below all the toolbars).
But because of that damn window manager raising the clicked window, this is quite impossible, at least without a very annoying flickering effect, and on X you need to handle a whole lot of race conditions. So instead they added the "transient for" attribute to try to get other windows to raise. As you pointed out, this *still* does not work (for instance it is useless if more than one document window shares a toolbar), and is enormously more complex to program than the simple actions if programs could just raise the windows themselves and assumme they are not raised otherwise.
The fact is that as long as the system does *anything* when you click other than tell the program "they clicked here" there is going to be bad GUI.
Linux copied the idea of /proc *from* Plan9, so there is certainly some resemblance!
/proc directly, without using a program, and get useful information (such as what files are open or the executable name, I've done both of these plenty of times).
Despite the limited nature of the copy (somebody else says that Linux version is pretty much read-only, I'm not sure) it shoud be obvious what a big win this is. Suddenly a whole lot of utilities like "ps" do not have to be recompiled to match the kernel. And you can peek into
The only other Plan-9 thing that is copied extensively is UTF-8 text encoding. This one is also a HUGE win, as suddendly we don't have to write two streams through all our programs for handiling Unicode and handling "legacy" ascii files, as they are now the same thing, as long as some (very minor) fixes are done to the "legacy" code. Plus UTF-8 seamlessly handled Unicode going past 65536 characters, while the "wide character" solution that Sun and HP and Dec and Microsoft struggled with for 20 years fell apart the moment this happened, by adding "surrogate characters" and thus deleting the *only* advantage it had over UTF-8.
Considering how incredibly useful both of these ideas are, I would certainly like to see a lot more of Plan 9 brought out into the real world. There is a lot there!
Actually Plan 9 does far better than "everything is an object". In Plan 9 everthing is a subclass of a certain base object, called a "file". Programs can assumme a set of useful functions, such as the ability to copy an object, that actually makes this api useful, rather than an academic experiment.
About all that "everything is an object" means is that it wont crash if you send the id for one type of object to an api designed for another type, instead you will get an error. Really the only difference between "everything is an object" and all existing operating systems is that the pool of id's for resources is shared between all types of resources.
There are certainly real usable object-oriented systems where there is a base class, but these then imply that "everything is an x" where x is that base class. And so far none of them have as simple of a base class as the Plan 9 file, or one that can actually be understood and used directly by a programmer rather than having to figure out the subclassing api.
You are right about that, I think. I am force to use Gnome at work and it cannot be set to do this. All my tests indicate that KDE works better.
What is really annoying is that I cannot assumme this because it is never the default. Especially because my software has to work on Windows as well. This bug seriously limits the ability to use multiple windows, the only way to make usable software is to not overlap the windows. The easiest way to do that is just to make a giant window and a "tiled" interface, like all other software has been forced to.
What really makes me mad about it is that the opposite would be trivial. If systems never raised windows, a program that *wants* click-to-top could easily get it by calling raise() on all clicks. So a whole class of useful GUI interaction is outlawed for no reason whatsoever...
Sigh. Almost there. ALMOST... We are so close to recovering the GUI technology that existed in 1985 or so.
Here's the idea: DON'T RAISE THE WINDOW WHEN THE USER CLICKS!!! The window should only raise if the user clicks the title bar or if the program does a raise() function.
This was figured out in 1984 (read the X10 release notes where they removed the automatic raise that was in earlier versions of X). It was then lost in 1990 or so becase Windows did not do this and all the sheep blindly copied them. Since then we have been subject to lots of tiled windows, odd-shaped control panels, and very small display areas, because overlapping windows are quite useless as long as you cannot interact with the underlying ones.
Now you have described some kind of elaborate thing using the scroll wheel, simply because they cannot figure it out:
CLICK != RAISE!!!
Actually, whether or not there was election fraud, Bush won the election. Under any plausable scenario which limits the fraud to the counties that are questionable, it would require something like 70% majority in those counties voting for Kerry (the fraud then reports this as 49%), to change the outcome of the election. This is astronomically unlikely when neighboring countines that are very similar in demographics and only differ by not having suspicious results, clearly voted only 49% for Kerry.
Equating "there was election fraud" with "Bush stole the election" is a right-wing piece of propaganda, designed to stop any such investigation. In fact the previous election (much more than the 2000 one) is ideal for investigating such fraud, precisely for the reason that it will not make a difference in outcome even if the worst possible imaginable fraud was detected.
I read both articles and I don't recall seeing anywhere that they would allow anyone access to their findings and research.
Actually this matches the GPL quite well. The GPL does not require you to make the source code publically available. It requires you to supply the source code to whoever you give/sell the program to. Thus there is no reason for the public to be able to see the code if all the parties agree to share only with themselves.
[The GPL also requires you to allow the person receiving the program to modify and redistribute it as they see fit, so they *could* make it publically available if they wanted. It is not clear if that is true here, probably not, so that is a difference]
Okay, I REALLY am stumped as to what you are thinking.
My new theory is that you think "UTF-8" is what I would call UCS-2, which is a 2-byte/character encoding. This would explain your claim that UTF-8 is "restricted to big-endian" which otherwise makes no sense. UCS-2 is what Microsoft originally used, and also what Sun and all the other idiots tried to force on us. I fully agree that UCS-2 is a bad idea!
UTF-8 uses from 1 to 4 *BYTES* per character and is not effected by endianess at all. UTF-8 has ALWAYS encoded every single position in Unicode, including every single one that requires surrogate pairs in UTF-16, and the original spec encoded character indexes up to 0x7fffffff, and that requirement was truncated to the limited range of UTF-16.
UTF-16 can be LOSSLESSLY translated to UTF-8. Therefore it is physically impossible that UTF-16 can provide any more functionality than UTF-8. There are no "glyph pairings" or anything else that can be done in UTF-16 that is "lost" in UTF-8.
The codes 0x800 through 0xffff do take 3 bytes in UTF-8 and only take 2 in UTF-16. However any real Chinese text will have enough spaces, numbers, and control characters (which only take 1 byte in UTF-8) to more than make up for this, and in fact real world texts are always shorter in UTF-8 in all languages. Comparing length is irrelevant anyway, as compression will make all encodings about equal in size.
I'm sorry, but you are the one that is confused. I'm not sure exactly what you are thinking, so I will try to correct this as well as I can:
UTF-8 was *ALWAYS* designed to encode far more than 64k characters. It was originally designed to go up to 0x7fffffff, but was cut down in the official standard at the same time UTF-16 was invented. The character 0x10ffff is encoded using 4 bytes, which happens to be the same length that UTF-16 requires. Here is a chart to make sure we are talking about the same thing:
(damn lameness filter probably means this is unreadable!)
UTF-8
0000 - 007F = 0abcdefg
0080 - 07FF = 110abcde 10fghijk
0800 - FFFF = 1110abcd 10efghij 10klmnop
10000-10FFFF = 11110abc 10defghi 10jklmno 10pqrstu
UTF-16
0000 - 007F = 00000000 0abcdefg
0080 - 07FF = 00000abc defghijk
0800 - FFFF = abcdefgh ijklmnop
10000-10FFFF = 110110ab cdefghij 110111kl mnopqrst (y=x-0x1000)
It is possible you are also confused by thinking that UTF-8 uses 6 bytes to do codes greater than 0xffff. This is in fact a problem with UTF-16 and stupid converters that don't understand UTF-16 surrogate pairs. These converters are BROKEN and in fact this is the fault of UTF-16 and stupid programmers, not a problem with UTF-8.
I'm also wondering if perhaps you are confusing UTF-16 with UTF-32 (or UCS-4 which is the same). That is to encode each character as a 4-byte word, which is the only practical way to make all of Unicode have the same number of bits per character. It is true that most processing of characters strings, especially to render them, passes through such a stage, since it is trivial to translate to glyphs. However nobody in their right mind would use that as a storage or transmission format. I also think this is misleading, as "combining characters" and more complex layout rules means that more than one code can really turn into a single glyph, and that we would be much better off if the programmers tried to work with variable-length encoding from the start, so they don't have to change gears so drastically when they suddenly run into variable-length layout rules.
I'm also wondering if perhaps you are confising UTF-8 with "8 bits per character", which obviously cannot store more than 256 characters.
UTF-16 is very misleading since there is a temptation to treat it as though each word is a glyph like UTF-32. This seems to be what you are thinking, and that is wrong. I do find it annoying that you are saying I have a "western bias" when in fact your ideas are the ones that make all the Chinese characters not work!
Despite your naive assumption that something with "16" in it's name is better than something with "8", the facts are that UTF-16 cannot handle as many characters:
UTF-16 as originally designed handles 0xffff characters.
Because that was not enough characters, UTF-16 was modified to have "surrogate pairs". Usually claimed to now handle 0x10ffff characters, but in fact they fail to subtract the surrogate half-characters (0x800). Also this deleted the only plausable claim that UTF-16 is better than UTF-8, in that characters all are the same number of bytes long (it is in fact worse, because the variable-length characters are much more rare, so bugs in handling them are much less likely to be detected and thus more catostrophic when they do happen).
UTF-8 as originally designed handles 0x7fffffff characters.
Because of the UTF-16 braindamage, the standards for UTF-8 were modified to say that all encodings after 0x10ffff are illegal, so literally UTF-8 was downgraded to match UTF-16. It still is false to say that you can losslessly translate from UTF-8 to UTF-16, due to the surrogate pairs, so they are not equivalent even with this limitation.
The one positive benifit of the "Unix wars" was that it stopped a whole lot of politically-correct idiots from forcing "wide characters" on everybody, and thus Plan9's UTF-8 could take hold. Unfortunatly Microsoft completely ignored all the proof that wide characters were a very bad idea and went and did it themselves in Windows. Still not as bad as if Unix had done it too...
The definatly did not alter POSIX, a colon passed to it is part of a filename, and a slash is always a sperator.
The swapping of colon and slash is done by the Carbon emulation.
You are correct that whether a Cocoa system does this depends on whether it calls POSIX or Carbon emulation. But I think almost all of Cocoa uses the POSIX api, as it is based on NeXTStep which was a Unix system.
This is wrong. The quoting is removed long before the filename is passed to the system.
I think you may be confusing it with backslash, which you can put in by doubling it (that will quote it, the quoting is stripped by the shell leaving a single backslash, and that is passed to the system, which treats it like any other character and puts it in the filename). However even with this, backslash is not recommended, since in many cases it will be passed through quoting-stripping more than once, such as when one script calls another and they are not correctly written.
This guy is complaining about the history-substitution in the Unix shells. This problem also exists on Windows if you use tcsh or something.
It is annoying sometimes. Backslash works a lot but I think it is inconsistent. Also I have never used ! except at the start of the line, command-line editing makes all other uses pretty obsolete, so removing this from a shell would probably be useful.
The windows users I know use '@' for the same purpose, oddly enough.
The actual limits were that the extension could not have more than 3 characters, and (more annoyingly) the extension always had to be there. The actual FAT storage had 11 bytes to stash the filename in, and it always stuck a period after the 8th character. The sections could be shorter by filling the unused bytes with null (? or maybe space?).
The filenames "foo" and "foo." were the same file. Programs were somewhat inconsistent as to whether they printed the period or not in this case.
You could actually make files named ".foo" which was convienent for Unix emulation, but only 3 letters. Also some programs crashed on that.
Breaching the lining and knocking out the pumps will flood the tunnel, drowning everybody inside it, and probably putting it out of commission for months or years.
http://uk.geocities.com/thetomcatslair/Entertainme nt/DRM/drm.html
...
Choice quotes:
First off, you need to download a few free programs: Windows Media Player (although I'm sure you've got this - it's bundled with every version of Windows since 98), the Nero Fast Burning Plugin (details from wmplugins.com and download from here),
This process does NOT work with Windows Media Player 10. See the FAQ Page for details.
Another possibility is that you bought the tracks from Napster. If so, Napster charge you extra to allow you to copy the song to a CD, and therefore, you can't remove the DRM using the method shown on my website.
http://club.cdfreaks.com/showthread.php?t=78454
* Backup music files from Napster/other companies that allow CD burning:
* Download the songs from Napster
* Burn the songs to a CD e.g. using Nero
* Rip the CD to MP3 e.g using Easy CDDA Creator
* Convert to any format you like e.g. using again Easy CDDA Creator
Now I am perhaps reading this wrong, but it sure sounds like you need a third party software called "Nero" to burn a CD. It is possible that the purpose of this software is to make a disk image to avoid using a real CD, however not ONCE have I seen anybody say "use WMP to burn a CD". Also it is pretty obvious that the WMA DRM allows a track to be marked as "can't make a CD from this".
Holy crap, you are really trying to look stupid!
A quick google for "wma drm burn cd" will reveal that protected WMA will *NOT* burn to a CD without third-party software. Something called "Nero" seems to be the most-mentioned way to do it.
Listen, I really don't think Microsoft fans are as stupid as you are trying to look. If this is some sort of troll to try to make them look bad, that is pretty shameful.