I don't like people feeling that they can copy my work for any purpose whatsoever without paying me, just because I allow some people to copy my work for free for specific purposes. For some reason they don't seem to have a problem with the fact that MicroSoft or Sun do not allow then to use their code for free, but the fact that I put the code under the GPL makes me somehow evil!
It is pretty obvious that the "posix standard" was forced through to conform to quick implementations of light-weight threads on existing single-threaded Unix systems.
Linux should ignore stupid standards. All information that is stored in the os should be seperate copies for each thread. There is no reason to share even file descriptors (they should be duped during clone and each process can seek() individually) The only things threads should share is their virtual memory. Light-weight threads can still be implemented by having calls like setuid() force the thread to become a heavy thread.
I would also like to see them get rid of the locks they put around virtually every system call (such as getc()!!!). The overhead of these is insane, and I really really can manage to do this on my own if I really have multiple threads reading from the same file.
I actually have not much idea what is going on, and am just trying to debug my program without learning details about how gdb and threads are implements. But so far (on a 4.2 machine) I have had good luck debugging mutliple threads with gdb, if I can get the thread to crash while running under gdb. It then seems to produce a stack dump and other information that is correct for the thread
I have had no success with setting break points and getting them to trigger. And I have absolutely no luck using core dumps generated when the program was not run under gdb. This is made more annoying because gdb changes something so that the code that I can crash easily when run directly does not crash when run under gdb. Pretty annoying!
Anybody have an explanation of what is going on?
PS: also don't use "-march=i686" in a multithreaded program. Is this a gcc bug?
New rule for slashdot: anybody posting this must name exactly the library they want, and show that it is not under the LGPL, BSD, or other "more free" license, and must document their attempts to purchase the rights to use the software in closed source and the fact that you were turned down.
Otherwise you have not shown the GPL to be hurting you in any way. I however am not happy with your desire to steal my code, depriving me of possible income from you buying it from me, and then go and try to accuse me of doing something dirty, when you are the immoral one.
What you want is to explicitly state that the code is "public domain". This has been done millions of times before, perhaps more often than the GPL has been invoked!
MicroSoft has somehow made people think that the only alternative to closed source is GPL? This is not good...
No. What you are reading is the rules where you can do *anything* with the source code, such as put it in a closed-source program (ie one that is not linked with the library). The intention is to keep useful functions that are inline in the headers from being put into closed-source. However if you use the inline function for purposes of calling the library it is considered a work that uses the library. If this was not true, the library writer either has to avoid long inline functions (a restriction that would be unacceptable to many), or they effectivly would have eliminated all reason to use the LGPL over the GPL.
My problem with the GPL is the "dynamic link requirement", which is still unconfirmed but believed by many people. Requiring dynamic linking is a source of bloat, instability, defeats the ability of the programmer to modify the library, and also is an enormous bias against "small" libraries that are not popular enough to be included with distributions. I have had to modify the LGPL with my code to explicitly say that static linking is allowed, but I consider this a somewhat evil, and even MicroSoftian tactic, to force things like the Gnome and Qt libraries on programmers.
Quoted releavant parts:
5....If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work.
(Executables containing this object code plus portions of the Library will still fall under Section 6.)
6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse engineering for debugging such modifications.
The answer is obvious: the device will allow you to exceed the speed limit for short periods of time in order to get out of emergency situations. Even if it is a minute or so this is pretty useless for people who want to speed but does not affect safety at all.
This argument against such devices is totally bogus. However it still does not mean they are a good idea.
Re:FOR loops: a question, ANSI C++, C++98, C++99..
on
GCC 3.0 Released
·
· Score: 2
I'm sure they can do the same thing gcc does, which is produce a warning message and then compile the code as it was before.
The Irix C++ compiler has this problem as well, but worse than VC++ because it produced an error if you declared a variable more than once (apparently VC++ silently allows this, which is why I was not even aware it did the scoping wrong until I tested it explicitly). The Irix problem meant that two for loops with the same "local" index variable would not compile, and since we also had compilers that obeyed C++ rules we have to insert the "int" declaration before the first for loop. This also broke a macro that relied on a local variable.
Fortunately the switch "-LANG:ansi-for-init-scope=ON" turns it on (they seem to have figured out how to be even more verbose than gcc, sigh...)
I just recently learned you turn this off (ie switch to C++ mode) with
Too many posters here seem to have no concept of a program that you can "run" without "installing" it first, and go on about how great apt-get is at "installing".
Listen to the orignal poster. The steps desired to run a new program are:
1. Download the file
2. Double click it.
3. It's running! No, it is not "installing", it is RUNNING!!!! Get that through your thick heads.
Also not mentioned is what the user does if they decide the program is crap and don't want it:
1. They drag the downloaded file to the trash (and empty it, I guess).
2. THAT'S IT! We are exactly in the same state as they were before they downloaded it. It does not "deinstall", it's one file!
What is being talked about has nothing to do with "installation".
If you want "installation" here is how it should work:
1. The user runs the program
2. The program somehow shows a question like "do you like this program and want it to appear in your Gnome/KDE startup, and in everybody else's (or for services, do you want to run it for real versus the simulation that is running now). The user clicks "yes".
3. It pops up a panel and asks for the root password.
4. It churns and it is "installed".
To "deinstall" you do this:
1. Somewhere in the system directories is a file with exactly the same name. You (as root) take this and put it in the trash. It's GONE!!!!
2. Somewhat later KDE/Gnome may notice that the menu items don't point at anything and hide or delete them.
How come nobody has tried some kind of "compression" file system that uses hash codes or something to locate identical blocks of files and maps them to the same place? This would allow thousands of copies of the same DLL to take much less disk space, and would even allow "static linked DLL" where the disk and memory are shared just because the pages are equal, and in general would work with no symbolic links or os support.
Would this work, or am I just clueless? Is anybody trying this? Never saw anything about it in all the file system discussion.
Woe is me to defend MicroSoft, but MFC really is equivalent to Qt, while the Win32 API's are equivalent to libc plus Xlib. Before you complain that somebody says "don't use MFC" you should realize that there are plenty of Linux people who say that for reliability you should not use Qt. The same argument applies to both systems.
PS: MFC is also as big a lock-in for MicroSoft as Word is. A huge stumbling block for getting programs ported to Linux is that they are written with MFC or VB systems. The MFC source code is totally useless for the port as it calls Win32 stuff (like structured file parsers) that nobody would ever use in any real code but MFC does so they can hide the implementation.
That link is used to locate the newest version when linking a new program. Already-linked programs have the version number in them and do not use the link (however after that it gets confusing and I do not understand it, it has complex rules to select from many possiblities and only the first number in the filename must match).
This can be demonstrated easily by removing those links, programs still work, but you cannot compile programs (or they find the static versions of the libraries).
You can use symbolic links to get DLL hell, as I will sheepishly admit I have to get downloaded programs to work. Link the version name of the library the program complained about to whatever version you have and often the program will work! However newer things like libc seem to have version information in the file that is checked so you can't outwit it that way.
I have been writing shared libraries for NT for awhile, and it does appear to do weird unpredictable things. I don't bother to figure it out, I just logout and back in (that seems to reset it) and continue.
I am just making normal DLL's (whatever you get when you "link/DLL" all your.obj files). It does appear it searches $PATH when it needs a DLL (I always must remember to delete my optimized copy, which is an earlier directory, before running if I want debugging to work). In this case it works exactly like LD_LIBRARY_PATH (which reminds me, I am just as confused by Linux as Windows. Why isn't this variable *always* needed, why is there some other mechanism to locate shared libraries?)
However one nasty screw up I have seen several times (but I can't reproduce at will, that's NT for you!) is that sometimes the other library will get "locked into memory", so that it refuses to load my new copy. I swear that I have exited, and even deleted, all the executables that are using that shared library, but it is still there! It appears that logout/in fixes it. Also deleting the library itself works (though that crashes running apps using it, why aren't the files locked like NT locks the executables?)
Another annoyance not mentioned here about NT is that you must use a DLL if you want to support "plugins" because all functions the plugins call must be in the DLL. Linux also has this but you can link your program with "-shared" and it then works like the Unix systems I am more familiar with (though I don't do this here as the software has to port to NT and repliating the difficulties of NT helps to keep things portable). For this reason I have to produce a DLL for no good reason at all, only my program uses it, and it is likely only one copy of my program is running at any time. I have heard there is some way to make a "DLL executable" but I can't locate it, just building a DLL out of all the source does not make a runnable program.
Another huge Windows annoyance is "__declspec__(dllexport)". That crap is going to pollute header files in code for ages after NT is dead and buried. What a waste.
Why the hell is there anything more complicated than this. I really want to be able to test the software without "installing" it.
Just put the libraries in there and fix the system so it is trivial for a program to turn argv[0] into it's execution location and it looks in that lokcation for shared libraries first. Yea, it's different, but it will be far better.
Or put the source code in there and when the user double-clicks it pops up a window that says "please wait, compiling gnucash" and then it works and is perfectly adapted to your system. This would be a huge win, and is something closed-source providers just cannot do! Don't worry about the time it takes, people are apparently willing to waste hours running "install" and the compile is nothing compared to that.
I think this idea has been suggested several times here, and is a good one. However it does mean the "application bundles all the libraries it uses". What you are saying is that the application does not necessarily use those libraries if the same version can be found in a more central place. Personally I feel this could be done with some kind of hash codeing of all the read-only pages swapped into memory, thus merging any matches without any version or file matching at all, but what do I know...
If electric cars catch on I would not be suprised if auto engineers produce "muscle" electric cars, possibly ones with torque so high they instantly obsolete internal combustion for people who want such cars.
Yes we don't know how to do it yet, but even today the most powerful motors are electric (in ships an railroad engines). The problem is that the generators of the electricity are too big (all such motors are to desiel or nuclear generators because that is the smallest way to produce that much electricity)
Just a note: most popular toolkits now work "at the lowest level". Besides Qt, GTK does. So does the smaller ones (fltk, jx, etc).
I think this is the proper way to do this. For somebody trying to support a program on multiple platforms, it is far more useful to have exact cross-platform identical interfaces, than to have this mythical and worshipped "common look and feel".
I would also like to find that mysterious user who is confused because the edges of the buttons look different between their programs. I think "common look and feel" is a crock, and all examples offered where it confuses people is when one of the options is also a completely stupid user interface (like Athena scrollbars). And this crock is forcing bloated toolkits (both Qt and KDE are bloated, and MFC is horrid) on everybody.
PS: I tried a "common user interface" and was forced to go back (in my case I tried to change all the menu shortcuts to Ctrl+ZXCV away from the Alt keys used before). It is painfully obvious that people easily learn differences between programs, but cannot handle the slightest changes in those programs over time.
Good point. It would certainly not be suprising if you were listed in the smarttags database, inserting this command in your page would cause you to be immediately removed.
The idea of automatic tags is not terrible at all. But only if there is a way for users to change their "smart tags server" so that they can pick the company they want (or perhaps merge several lists). (I think something that points at a user-generated data like everything2 would be pretty neat). The fact that MicroSoft has not indicated any ability to change the server is a good sign of their actual intentions!
PS: a "pick the server you want" with an open-source database format would be an acceptable way to implement censorware.
Truth is, the depression was caused by hundreds of factors. There is at least one in there for every possible political persuasion be able to say "they didn't do it my way, and that caused the depression!"
The problem is that the "enforcement at the point of a gun" is of the higher price, you have some delusion that the forcing is the reverse.
Stop trying to say this is some Communist plot to steal movies. In reality it is the MPAA that is doing Communist/Socialist things, using government power to meddle with the free market. If it were not for government rules put into place due to the MPAA, DVD players from the USA would be imported and sold there, and disks from the USA would be imported and sold there, and region encoding would be useless.
I would agree that the repair required is to get rid of these trade barriers, not further regulations like "you must sell the disks for the same price as in the US". Such regulations always have bad side effects...
Yes, I am guessing that MS picked a character to mean "backwards wrapping space" or something, and it sounds like all Arabic must have the words seperated by this character rather than space. It apparently is not the "non breaking space" or some Arabic equivalent, if I understand the orginal poster correct.
The question was "did they do this for a good reason? Ie: doing this allows formatting control that could not be achieved otherwise. Or were they just stupid/lazy, and if normal spaces were used with a slightly smarter program would it be just as good?
I personally don't know anything about Arabic so I cannot answer these questions. My guess is that this is reasonable if there is a place that "normal spaces" are used in Arabic.
For European languages that could be represented in ISO-8859-1 it is true that the foreign letters turn from 1 to 2 bytes in UTF-8. Since this is a fraction of the characters the increase in size is really only about 5% at most. This seems a reasonable payoff for the fact that we can now support all those languages that could not be supported in ISO-8859-1.
But wait, there is more:
I propose (is there any official way to do it) that the official standard be to interpret "malformed sequences" (ie bytes which don't form a correct minimal-length UTF-8 encoding) as being the raw 8-bit bytes. This will allow almost all ISO-8859-1 text to pass through even though it is not encoded in UTF-8, because you would have to put a foreign punctuation mark followed by 2 accented characters for it to be mistaken as a UTF-8 character, or a C1 control character followed by an accented character, this is very rare.
I also think all UTF-8 sequences that encode characters longer than the minimal encoding should be considered illegal and be interpreted as individual bytes. This greatly increases the ability of plain ISO-8859-1 text to go through, and avoids what I expect will be a security bug-fest when people fool things into accepting slashes and newlines and semicolons that the programs thing they are filtering out.
This idea avoids problems in the standard for determining when a malformed sequence ends (ie does a prefix followed by a 7-bit character mean a single error or an error and a character?).
It also eliminates the need for there to be an "error" character or any kind of error state in UTF-8 parsing, as all possible sequences of bytes are legal sequences. This vastly simplifies the programming interface.
And it has the side effect that almost 100% of European text is the same length in UTF-8 as ISO-8859-1.
Re:Animated Gif anarchy since 0.9 (AAARGH!!)
on
Mozilla 0.9.1 Out
·
· Score: 3
It would be real nice if there was a "play this once" and "play this continuous" and "stop" on the pop-up menu, though. Just in case you want to control the animations individually. And some preference for the intial state of all of them.
Huh? I thought the fact that IE rendered as much as possible as it downloaded was one of it's advantages. Though in my experiments it seems to act like Netscape 4.0, it's main advantage is that it is generally faster and it still draws the page if there are missing tags (ie if it is blocked and you hit stop you see something).
If we are going to waste computer time, I think Mozilla should continuously guess at any missing data (ie guess that images are the same size as the last image, add missing close tags, whatever) and continuously redraw the window while it is downloading. Ie if it has got data in memory and is not busy reading more data it should do as much as possible to get it on the screen. Perhaps it does do this?
Slashdot Mirror
I don't like people feeling that they can copy my work for any purpose whatsoever without paying me, just because I allow some people to copy my work for free for specific purposes. For some reason they don't seem to have a problem with the fact that MicroSoft or Sun do not allow then to use their code for free, but the fact that I put the code under the GPL makes me somehow evil!
Linux should ignore stupid standards. All information that is stored in the os should be seperate copies for each thread. There is no reason to share even file descriptors (they should be duped during clone and each process can seek() individually) The only things threads should share is their virtual memory. Light-weight threads can still be implemented by having calls like setuid() force the thread to become a heavy thread.
I would also like to see them get rid of the locks they put around virtually every system call (such as getc()!!!). The overhead of these is insane, and I really really can manage to do this on my own if I really have multiple threads reading from the same file.
I have had no success with setting break points and getting them to trigger. And I have absolutely no luck using core dumps generated when the program was not run under gdb. This is made more annoying because gdb changes something so that the code that I can crash easily when run directly does not crash when run under gdb. Pretty annoying!
Anybody have an explanation of what is going on?
PS: also don't use "-march=i686" in a multithreaded program. Is this a gcc bug?
Otherwise you have not shown the GPL to be hurting you in any way. I however am not happy with your desire to steal my code, depriving me of possible income from you buying it from me, and then go and try to accuse me of doing something dirty, when you are the immoral one.
What you want is to explicitly state that the code is "public domain". This has been done millions of times before, perhaps more often than the GPL has been invoked!
MicroSoft has somehow made people think that the only alternative to closed source is GPL? This is not good...
No. What you are reading is the rules where you can do *anything* with the source code, such as put it in a closed-source program (ie one that is not linked with the library). The intention is to keep useful functions that are inline in the headers from being put into closed-source. However if you use the inline function for purposes of calling the library it is considered a work that uses the library. If this was not true, the library writer either has to avoid long inline functions (a restriction that would be unacceptable to many), or they effectivly would have eliminated all reason to use the LGPL over the GPL.
My problem with the GPL is the "dynamic link requirement", which is still unconfirmed but believed by many people. Requiring dynamic linking is a source of bloat, instability, defeats the ability of the programmer to modify the library, and also is an enormous bias against "small" libraries that are not popular enough to be included with distributions. I have had to modify the LGPL with my code to explicitly say that static linking is allowed, but I consider this a somewhat evil, and even MicroSoftian tactic, to force things like the Gnome and Qt libraries on programmers.
Quoted releavant parts:
5. ...If such an object file uses only numerical parameters, data structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object file is unrestricted, regardless of whether it is legally a derivative work.
(Executables containing this object code plus portions of the Library will still fall under Section 6.)
6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.
This argument against such devices is totally bogus. However it still does not mean they are a good idea.
The Irix C++ compiler has this problem as well, but worse than VC++ because it produced an error if you declared a variable more than once (apparently VC++ silently allows this, which is why I was not even aware it did the scoping wrong until I tested it explicitly). The Irix problem meant that two for loops with the same "local" index variable would not compile, and since we also had compilers that obeyed C++ rules we have to insert the "int" declaration before the first for loop. This also broke a macro that relied on a local variable.
Fortunately the switch "-LANG:ansi-for-init-scope=ON" turns it on (they seem to have figured out how to be even more verbose than gcc, sigh...) I just recently learned you turn this off (ie switch to C++ mode) with
Too many posters here seem to have no concept of a program that you can "run" without "installing" it first, and go on about how great apt-get is at "installing".
Listen to the orignal poster. The steps desired to run a new program are:
1. Download the file
2. Double click it.
3. It's running! No, it is not "installing", it is RUNNING!!!! Get that through your thick heads.
Also not mentioned is what the user does if they decide the program is crap and don't want it:
1. They drag the downloaded file to the trash (and empty it, I guess).
2. THAT'S IT! We are exactly in the same state as they were before they downloaded it. It does not "deinstall", it's one file!
What is being talked about has nothing to do with "installation".
If you want "installation" here is how it should work:
1. The user runs the program
2. The program somehow shows a question like "do you like this program and want it to appear in your Gnome/KDE startup, and in everybody else's (or for services, do you want to run it for real versus the simulation that is running now). The user clicks "yes".
3. It pops up a panel and asks for the root password.
4. It churns and it is "installed".
To "deinstall" you do this:
1. Somewhere in the system directories is a file with exactly the same name. You (as root) take this and put it in the trash. It's GONE!!!!
2. Somewhat later KDE/Gnome may notice that the menu items don't point at anything and hide or delete them.
Would this work, or am I just clueless? Is anybody trying this? Never saw anything about it in all the file system discussion.
PS: MFC is also as big a lock-in for MicroSoft as Word is. A huge stumbling block for getting programs ported to Linux is that they are written with MFC or VB systems. The MFC source code is totally useless for the port as it calls Win32 stuff (like structured file parsers) that nobody would ever use in any real code but MFC does so they can hide the implementation.
This can be demonstrated easily by removing those links, programs still work, but you cannot compile programs (or they find the static versions of the libraries).
You can use symbolic links to get DLL hell, as I will sheepishly admit I have to get downloaded programs to work. Link the version name of the library the program complained about to whatever version you have and often the program will work! However newer things like libc seem to have version information in the file that is checked so you can't outwit it that way.
I am just making normal DLL's (whatever you get when you "link /DLL" all your .obj files). It does appear it searches $PATH when it needs a DLL (I always must remember to delete my optimized copy, which is an earlier directory, before running if I want debugging to work). In this case it works exactly like LD_LIBRARY_PATH (which reminds me, I am just as confused by Linux as Windows. Why isn't this variable *always* needed, why is there some other mechanism to locate shared libraries?)
However one nasty screw up I have seen several times (but I can't reproduce at will, that's NT for you!) is that sometimes the other library will get "locked into memory", so that it refuses to load my new copy. I swear that I have exited, and even deleted, all the executables that are using that shared library, but it is still there! It appears that logout/in fixes it. Also deleting the library itself works (though that crashes running apps using it, why aren't the files locked like NT locks the executables?)
Another annoyance not mentioned here about NT is that you must use a DLL if you want to support "plugins" because all functions the plugins call must be in the DLL. Linux also has this but you can link your program with "-shared" and it then works like the Unix systems I am more familiar with (though I don't do this here as the software has to port to NT and repliating the difficulties of NT helps to keep things portable). For this reason I have to produce a DLL for no good reason at all, only my program uses it, and it is likely only one copy of my program is running at any time. I have heard there is some way to make a "DLL executable" but I can't locate it, just building a DLL out of all the source does not make a runnable program.
Another huge Windows annoyance is "__declspec__(dllexport)". That crap is going to pollute header files in code for ages after NT is dead and buried. What a waste.
Why the hell is there anything more complicated than this. I really want to be able to test the software without "installing" it.
Just put the libraries in there and fix the system so it is trivial for a program to turn argv[0] into it's execution location and it looks in that lokcation for shared libraries first. Yea, it's different, but it will be far better.
Or put the source code in there and when the user double-clicks it pops up a window that says "please wait, compiling gnucash" and then it works and is perfectly adapted to your system. This would be a huge win, and is something closed-source providers just cannot do! Don't worry about the time it takes, people are apparently willing to waste hours running "install" and the compile is nothing compared to that.
I think this idea has been suggested several times here, and is a good one. However it does mean the "application bundles all the libraries it uses". What you are saying is that the application does not necessarily use those libraries if the same version can be found in a more central place. Personally I feel this could be done with some kind of hash codeing of all the read-only pages swapped into memory, thus merging any matches without any version or file matching at all, but what do I know...
I think you grossly underestimate the horizontal distance involved!
Yes we don't know how to do it yet, but even today the most powerful motors are electric (in ships an railroad engines). The problem is that the generators of the electricity are too big (all such motors are to desiel or nuclear generators because that is the smallest way to produce that much electricity)
I think this is the proper way to do this. For somebody trying to support a program on multiple platforms, it is far more useful to have exact cross-platform identical interfaces, than to have this mythical and worshipped "common look and feel".
I would also like to find that mysterious user who is confused because the edges of the buttons look different between their programs. I think "common look and feel" is a crock, and all examples offered where it confuses people is when one of the options is also a completely stupid user interface (like Athena scrollbars). And this crock is forcing bloated toolkits (both Qt and KDE are bloated, and MFC is horrid) on everybody.
PS: I tried a "common user interface" and was forced to go back (in my case I tried to change all the menu shortcuts to Ctrl+ZXCV away from the Alt keys used before). It is painfully obvious that people easily learn differences between programs, but cannot handle the slightest changes in those programs over time.
The idea of automatic tags is not terrible at all. But only if there is a way for users to change their "smart tags server" so that they can pick the company they want (or perhaps merge several lists). (I think something that points at a user-generated data like everything2 would be pretty neat). The fact that MicroSoft has not indicated any ability to change the server is a good sign of their actual intentions!
PS: a "pick the server you want" with an open-source database format would be an acceptable way to implement censorware.
Truth is, the depression was caused by hundreds of factors. There is at least one in there for every possible political persuasion be able to say "they didn't do it my way, and that caused the depression!"
Stop trying to say this is some Communist plot to steal movies. In reality it is the MPAA that is doing Communist/Socialist things, using government power to meddle with the free market. If it were not for government rules put into place due to the MPAA, DVD players from the USA would be imported and sold there, and disks from the USA would be imported and sold there, and region encoding would be useless.
I would agree that the repair required is to get rid of these trade barriers, not further regulations like "you must sell the disks for the same price as in the US". Such regulations always have bad side effects...
The question was "did they do this for a good reason? Ie: doing this allows formatting control that could not be achieved otherwise. Or were they just stupid/lazy, and if normal spaces were used with a slightly smarter program would it be just as good?
I personally don't know anything about Arabic so I cannot answer these questions. My guess is that this is reasonable if there is a place that "normal spaces" are used in Arabic.
But wait, there is more:
I propose (is there any official way to do it) that the official standard be to interpret "malformed sequences" (ie bytes which don't form a correct minimal-length UTF-8 encoding) as being the raw 8-bit bytes. This will allow almost all ISO-8859-1 text to pass through even though it is not encoded in UTF-8, because you would have to put a foreign punctuation mark followed by 2 accented characters for it to be mistaken as a UTF-8 character, or a C1 control character followed by an accented character, this is very rare.
I also think all UTF-8 sequences that encode characters longer than the minimal encoding should be considered illegal and be interpreted as individual bytes. This greatly increases the ability of plain ISO-8859-1 text to go through, and avoids what I expect will be a security bug-fest when people fool things into accepting slashes and newlines and semicolons that the programs thing they are filtering out.
This idea avoids problems in the standard for determining when a malformed sequence ends (ie does a prefix followed by a 7-bit character mean a single error or an error and a character?).
It also eliminates the need for there to be an "error" character or any kind of error state in UTF-8 parsing, as all possible sequences of bytes are legal sequences. This vastly simplifies the programming interface.
And it has the side effect that almost 100% of European text is the same length in UTF-8 as ISO-8859-1.
It would be real nice if there was a "play this once" and "play this continuous" and "stop" on the pop-up menu, though. Just in case you want to control the animations individually. And some preference for the intial state of all of them.
If we are going to waste computer time, I think Mozilla should continuously guess at any missing data (ie guess that images are the same size as the last image, add missing close tags, whatever) and continuously redraw the window while it is downloading. Ie if it has got data in memory and is not busy reading more data it should do as much as possible to get it on the screen. Perhaps it does do this?