I am not trying to be a troll. Using UTF-8 for everything, including internal storage, will be a big win in code size and speed. This is for a very simple reason: everything you write now and for a long time to come is going to have to import/export 8-bit files. Use of UTF-8 eliminates the need to duplicate algorithims in 32 bit and 8 bit form.
I would estimate that 99.5% of all the processing done on character strings will work with UTF-8 if they just treated bytes with the high bit set as "letters".
For instance there is absolutely no reason strlen() has to return any value other than the number of bytes in a string and it should be obvious that you don't have to rewrite it for this. Take a look at every use of strlen you can find and see if it is ever used for any purpose other than to measure how much memory is needed to store the string. I think you will find there are zero other uses.
Though less obvious, the same thing is true of almost every other operation done in C on characters.
Another way of looking at it is to remember that English (and most other languages) are made of "words" and these "words" are already stored as "multibyte sequences". But writing code that does not break up words (which would make it unreadable) apparently is not too hard, and nobody seems to thing that "p = nextword(p)" is a function that needs to be in the C library.
If you are still convinced that having fixed-size storage for each character is important, the other killer is that wchar does not solve it!. Look up "combining characters" and you will see.
I am sorry about ranting, but imho "wide characters" are one of the most stupid things ever invented, they are pushed by people who who fear being politically incorrect (ie "don't show a bias toward English") and have made it impossible to do internationalization where we can just look at a text file and see it in the language it was written.
Step 3: If you think you need to use fixed-sized characters, think again and use UTF-8.
Step 4: search for and delete all remaining occurances of "wchar" and replace with UTF-8
Step 5: delete C++ string and stream templates that think the storage unit has to be bigger than 8 bits, making them far faster and smaller and easier to debug. Delete all "if" statements that test the "size of a character". Delete all interfaces that take "strings" that are made of things bigger than bytes. Watch your code get far, far smaller and faster and suddenly work in multiple locales!
Step 6: Did I forget to mention you should use UTF-8 for everything!
Thank you, I hope my instructions have been helpful in giving you a clue.
Today, it seems, we've turned the tables. "30 packages? What a pain! Why don't they just give me one big package that I can click?"
Because the 21 bug patches are useful independently (moreso in that a few weeks ago there were only, say, 15, and if you had gotten those, you would only need to download 6 today).
With gnome is those 30 packages are effectively 1/30th of a big blob due to a web of interdependencies. Individually they are useless, or maybe worse than useless as they will break your old Gnome installation?
Seriously, if Windoze was really open, like they gave out all the source necessary so that you could compile something that would run any Windoze applications, I would expect that very quickly this source would be modified to add missing Unix functionality.
Probably number one on the list would be symbolic links, and a scheme so that the filename "/A/" means the same as "A:/".
fork() (merged with their threads)
Removal of the case-insensitive filenames, or at least a hack so that files with different cases can exist at the same time and the closest match to a typed is used.
Fix libc so that writing text files does not insert CR characters (reading them can still strip them for back-compatability).
There are probably dozens of others. All little things that MicroSoft has put in there purposely to make it difficult to port software back and forth. The result would not be Unix, but it would make the system play nice with Unix and still run Windoze programs.
What does "distribute" mean. Can two friends share GPL code amongst themselves without running afoul of the slashdotters? Can Bill Gates share his private version of emacs with Steve Ballmer?
As I read it, Bill Gates is required by the GPL to give Steve Ballmer the code to his specially modified Emacs.
If Steve gives the Emacs to another party, he is required to give them the code. So if Steve posted it on the web, he must make the code available to the world. And the GPL requires that Steve be able to do this.
But the GPL does not require that Steve do this. Steve may "promise" Bill Gates that he will not redistribute the program. As long as Bill Gates trusts Steve, he can assumme nobody will have his private Emacs code.
A company like Corel cannot force somebody to obey such a "promise", because if the promise is a legal document it violates the GPL. A receiver who redistributes the code is perfectly legal. Corel can fire them (if they are employees) or give them bad beta-tester karma points, but cannot take legal action.
I don't know what this guy is talking about. VC++ compiles quite quickly, even from the command line and even without using "incremental" (which we don't because it does not like CVS or using any editor other than the built-in one).
For many small source files, gcc is faster. For a big source file it appears VC++ is faster. This would indicate that VC++ has a lot of startup overhead (a common MSoft problem), but they have certainly worked on the innards.
The output code is definately more compact than gcc. They have worked a lot on making VC++ optimized. Hate to say it, but they are way ahead here. However, they also don't seem to have much concern for bugs, we have many pieces of software that do not compile in optimized mode due to VC++ bugs. (gcc can almost 100% be assummed to work optimized, if your program works in debug)
VC++ really loses in a few places: you cannot use the IDE and retain any control over the linking or location of your files, and those F*KING _dllexport macros are one of the worst pieces of garbage that are polluting all portable code...
Um, maybe I have my philosophers mixed up. Which one was the communist, Ayn Rand?
Re:I think they are going in the wrong direction h
on
The Future of KDE
·
· Score: 1
Steve Jobs had a bad experience in childhood when he pushed the wrong button on a mouse, and it has tainted him for life.
Witness the original NeXT machine, which had a two-button mouse: but they acted the same! And this same-acting was not in the toolkit or at any software level, it was in the window server, so that it was *impossible* for a program to differentiate the buttons no matter how much it wanted to (you could send a command to the window server but that would split the buttons for all the apps).
There is something called UTF-8. It means your text is stored in the same space it was before but it contains not just 65536 characters, but 2^31 possible characters, and you NEVER have to put an "if" in there to say "wide or normal characters". And all the c string functions still work, and they are FAST and byte-oriented.
"Wide characters" are the biggest impediment to internationalization there is. We would be much better off if everybody was using ASCII because there would not be those "if" statements and "character sets" that any correct Unicode system has to be compatable with. Please don't add this crap to yet another toolkit and environment.
PS: It has already taken Qt down with it. Qt now copies every string argument you pass it to it's own memory in order to pad it to 16 bits. This is an annoying, horrible waste of time for the vast majority of users, and makes it impossible to pass UTF-8, and has noticably slowed all the KDE applications.
No way! One of the big wins of X is that it does not try to implement any GUI components. If it did, X would look precisely like it did in 1983 and it would be very very lousy!
I also don't understand this weird belief that users are somehow "confused" by buttons that are different colors or have somewhat different patterns of pixels around them. I would like to see an actual example of such a confused user. In fact I think having the applications be somewhat different in appearance helps considerably in identifying which window belongs to which, and avoiding the gray mess that is a Windoze desktop.
This is not to be confused with the "different actions" problem that plagued X, like toolkits disagreeing about what each mouse button did in a scrollbar, and editors that disagree about what each key does. This was (and still is) a horrid problem for X, but it *is* being solved, mostly by the deletion of stupid things from toolkits, and without making the X server enforce it!
Um, exactly how do you change all these 23 applications using an entry in the.Xdefaults file? In my experience, even if every one of them is using Motif, I cannot even get the background color to change with a single line of.Xdefaults.
What happens if a.Xdefaults/resources/whatever file gets corrupted? Your application starts up with a perfactly usable set of options.
Not in my experience. Motif programs that have missing or corrupt.appdefault files are totally useless (like, the buttons have no labels!). I 100% agree with the initial author that these have the same problems as the windoze registry. I have never seen a Motif appdefault file that is editable, they are just "part of the program" and have to exist, unchanged from how the author wrote them.
And even if they did work, this is a horribly user-unfriendly way to customize a program!
I am not saying that you would look in the Mozilla code and see X calls. That is also stupid. What they should do is write a "toolkit", but that "toolkit" is totally dedicated to running Mozilla, and is statically linked with it, and the source code is right there with the Mozilla source code. It would provide a portability layer over the various windowing systems (on Windoze it should use WIN32 api only).
Multi-application toolkits have their uses, but on a system as large and complex as Mozilla it is much more efficient and less bug-prone to write everything at a very low level. In my experience it takes more code to interface to a toolkit when you need it to perform the slightest different than it was designed, than to just write all the gui widgets at a low level.
This was one of the reasons I created a toolkit of my own ( fltk). I tried to design it so that it could be static linked, and if you needed to make it work with your appliation, you were free to change the internal code and make it into an application-specific toolkit. I am actually rather disappointed that fltk is pretty much being used just like other toolkits, including the making of it into a shared library, which is exactly not what I intended...
I wish Mozilla all the luck in making the "Xlib" version and really look forward to seeing it. IMHO this version will be vastly superior in every way, and I do wish they would devote all their resources to it.
If there are libraries that are only used by Mozilla they should be STATICALLY LINKED!
What are they thinking? Seems like everybody on Linux is anxious to replicate the DLL hell of Windoze.
Static linking is not evil and can actually be far more efficient. Unless you have absolute proof that a second appliation will use the functionality (not just "this is so neat of a function that somebody might want to reuse it"), please don't make a shared library!
DUH! I think if you look a little at that "fast scrolling Windoze program" you will find it is using the WIN32 API and not directly writing it's characters to some frame buffer. On NT it definately goes through a context switch (don't know about Win95).
The WIN32 API is exactly equivalent to the Xlib api. You send it letters and some other part of the code draws them. You don't draw pixels to a frame buffer.
Not that X is blameless. It is slower. This is mostly due to a bad design defect such that scrolling regions requires synchronous communication between the app and the server. This can be avoided and async scrolling implemented by nested multiple windows but most people don't know that.
I would also blame bad toolkit programming (is this a Motif program?), the assinine adding of "wide characters" to the interface, and the horrid font system inside X.
Pipes are a big win and can greatly reduce context switches. *Many* requests can be put into a buffer before a context switch is made. This has nothing to do with whether the GUI is in the kernel or not, a kernel GUI could also use pipes and be faster.
Problem with X is some bad design so that synchronous communication is required to do some things (like select colors!) and some bad programming in toolkits so that synchronous communication is done even when it is unnecessary. In this case pipes don't buy you anything, and if only one command is done between each sync then you pay for the overhead of the buffering code.
I agree, there needs to be better integration between the normal X drawing and the OpenGL drawing. It would help a lot if the current OpenGL transformation applied to everything, so that you could do perspective and then do X drawing and comes out as though drawn on a flat surface angled that direction in space.
Maybe we will see it someday. I think they should plan for it. This requires making a GLXcontext and an X "GC" be the same object, making OpenGL start up with an "identity" transformation that matches the X coordinates (currently it comes up undefined), and as a temporary stopgap, making all X drawing not work if the current GL transform is not the identity or if Z buffer is on (so that people don't use it and then complain later on when it does not work).
I would also like to see X *always* provide a 32-bit true color visual and fake it on the display hardware, so we could stop thinking about those stupid colormaps!
If Windows 2000 source code was stolen today, how much would it be worth?
Seriously, pretty close to nothing. Do you really think somebody who would have bought a copy of Windoze would not because they can now get a "free copy compiled from the source". They can get a free copy now (just copy it off another Windoze machine), and much better and more reliable than some source compilation that may not exactly match MS's distribution, and certainly does not contain any bug fixes made since the code was stolen.
And the code can be looked at by people writing WINE, but that is illegal, the code was stolen. Nobody legit would dare go near it, in fact it is possible to see the source code now (many universities and companies have it under NDL) and using that for products is illegal as well, so there is not loss right now.
My conclusion is that stolen source code is worth almost exactly zero.
Remember that the context switch is not needed per Xlib call, but only when the buffer fills up. In fact the percentage overhead of the context switch can be reduced to very small by not doing XFlush excessively (there are programs out there, especially ones written by people who are used to direct hardware access, that do XFlush and XSync all the time, resulting in horrid performance).
There are huge wins besides networking with getting all the graphics into it's own process and easily worth the overhead.
GEM did have some aspects that indicated that certified morons were at least partially responsible for it's design.
Best example is that they detected double clicks by waiting until the time has passed before sending a "single click" or a "double click" event to the application. This of course meant the system had a built-in delay in responding to any clicks. As an exercise to the reader, try to figure out a better interface (you have 12 seconds to answer).
Get Sun to release NeWS! Now that would be a great thing to have. It would be nice to get both the original Gosling code and the somewhat broken version which had X11 compatability.
While RedHat is "making millions" distributing this work of others, even others are "making millions" by "stealing" RedHat's work. Or didn't you notice all those new distributions that are "based on RedHat". You can be sure they didn't pay RedHat anything (well they may have bought a disk) and are profiting off RedHat's labor!
I think this is a good indication that Free Software works. You just said somebody is making millions off it, even though others can "steal" it for free. So where is the complaint?
In fact to speed it up (I think, I don't really know how the browser works) this can be a pull-down menu of levels instead of a lot of buttons, with the current setting preselected. The moderator can then pick a different setting if desired. When the scores are reported back the score is moved one point toward the score the moderator picked.
The menu should be limited to the range -1 to 10 (?). To allow numbers outside this range there could be an item "higher" that acts like 11 unless the score is already >= 11 in which case it adds one. There could also be a "lower" but I think a concrete bottom of -1 or -2 is a better idea.
How about that? It would be nice if they documented that. Actually it would be even nicer if they just detected this fact, surely they can check to see if their own window manager is running!
I wrote a window manager (flwm) and tried to get kde apps to run under it and everything seems to work except kpanel. I'll try this switch soon.
Slashdot Mirror
I would estimate that 99.5% of all the processing done on character strings will work with UTF-8 if they just treated bytes with the high bit set as "letters".
For instance there is absolutely no reason strlen() has to return any value other than the number of bytes in a string and it should be obvious that you don't have to rewrite it for this. Take a look at every use of strlen you can find and see if it is ever used for any purpose other than to measure how much memory is needed to store the string. I think you will find there are zero other uses.
Though less obvious, the same thing is true of almost every other operation done in C on characters.
Another way of looking at it is to remember that English (and most other languages) are made of "words" and these "words" are already stored as "multibyte sequences". But writing code that does not break up words (which would make it unreadable) apparently is not too hard, and nobody seems to thing that "p = nextword(p)" is a function that needs to be in the C library.
If you are still convinced that having fixed-size storage for each character is important, the other killer is that wchar does not solve it!. Look up "combining characters" and you will see.
I am sorry about ranting, but imho "wide characters" are one of the most stupid things ever invented, they are pushed by people who who fear being politically incorrect (ie "don't show a bias toward English") and have made it impossible to do internationalization where we can just look at a text file and see it in the language it was written.
Step 1: Use UTF-8
Step 2: Use UTF-8 for everything.
Step 3: If you think you need to use fixed-sized characters, think again and use UTF-8.
Step 4: search for and delete all remaining occurances of "wchar" and replace with UTF-8
Step 5: delete C++ string and stream templates that think the storage unit has to be bigger than 8 bits, making them far faster and smaller and easier to debug. Delete all "if" statements that test the "size of a character". Delete all interfaces that take "strings" that are made of things bigger than bytes. Watch your code get far, far smaller and faster and suddenly work in multiple locales!
Step 6: Did I forget to mention you should use UTF-8 for everything!
Thank you, I hope my instructions have been helpful in giving you a clue.
Because the 21 bug patches are useful independently (moreso in that a few weeks ago there were only, say, 15, and if you had gotten those, you would only need to download 6 today).
With gnome is those 30 packages are effectively 1/30th of a big blob due to a web of interdependencies. Individually they are useless, or maybe worse than useless as they will break your old Gnome installation?
Probably number one on the list would be symbolic links, and a scheme so that the filename "/A/" means the same as "A:/".
fork() (merged with their threads)
Removal of the case-insensitive filenames, or at least a hack so that files with different cases can exist at the same time and the closest match to a typed is used.
Fix libc so that writing text files does not insert CR characters (reading them can still strip them for back-compatability).
There are probably dozens of others. All little things that MicroSoft has put in there purposely to make it difficult to port software back and forth. The result would not be Unix, but it would make the system play nice with Unix and still run Windoze programs.
As I read it, Bill Gates is required by the GPL to give Steve Ballmer the code to his specially modified Emacs.
If Steve gives the Emacs to another party, he is required to give them the code. So if Steve posted it on the web, he must make the code available to the world. And the GPL requires that Steve be able to do this.
But the GPL does not require that Steve do this. Steve may "promise" Bill Gates that he will not redistribute the program. As long as Bill Gates trusts Steve, he can assumme nobody will have his private Emacs code.
A company like Corel cannot force somebody to obey such a "promise", because if the promise is a legal document it violates the GPL. A receiver who redistributes the code is perfectly legal. Corel can fire them (if they are employees) or give them bad beta-tester karma points, but cannot take legal action.
For many small source files, gcc is faster. For a big source file it appears VC++ is faster. This would indicate that VC++ has a lot of startup overhead (a common MSoft problem), but they have certainly worked on the innards.
The output code is definately more compact than gcc. They have worked a lot on making VC++ optimized. Hate to say it, but they are way ahead here. However, they also don't seem to have much concern for bugs, we have many pieces of software that do not compile in optimized mode due to VC++ bugs. (gcc can almost 100% be assummed to work optimized, if your program works in debug)
VC++ really loses in a few places: you cannot use the IDE and retain any control over the linking or location of your files, and those F*KING _dllexport macros are one of the worst pieces of garbage that are polluting all portable code...
Um, maybe I have my philosophers mixed up. Which one was the communist, Ayn Rand?
Witness the original NeXT machine, which had a two-button mouse: but they acted the same! And this same-acting was not in the toolkit or at any software level, it was in the window server, so that it was *impossible* for a program to differentiate the buttons no matter how much it wanted to (you could send a command to the window server but that would split the buttons for all the apps).
There is something called UTF-8. It means your text is stored in the same space it was before but it contains not just 65536 characters, but 2^31 possible characters, and you NEVER have to put an "if" in there to say "wide or normal characters". And all the c string functions still work, and they are FAST and byte-oriented.
"Wide characters" are the biggest impediment to internationalization there is. We would be much better off if everybody was using ASCII because there would not be those "if" statements and "character sets" that any correct Unicode system has to be compatable with. Please don't add this crap to yet another toolkit and environment.
PS: It has already taken Qt down with it. Qt now copies every string argument you pass it to it's own memory in order to pad it to 16 bits. This is an annoying, horrible waste of time for the vast majority of users, and makes it impossible to pass UTF-8, and has noticably slowed all the KDE applications.
I also don't understand this weird belief that users are somehow "confused" by buttons that are different colors or have somewhat different patterns of pixels around them. I would like to see an actual example of such a confused user. In fact I think having the applications be somewhat different in appearance helps considerably in identifying which window belongs to which, and avoiding the gray mess that is a Windoze desktop.
This is not to be confused with the "different actions" problem that plagued X, like toolkits disagreeing about what each mouse button did in a scrollbar, and editors that disagree about what each key does. This was (and still is) a horrid problem for X, but it *is* being solved, mostly by the deletion of stupid things from toolkits, and without making the X server enforce it!
Um, exactly how do you change all these 23 applications using an entry in the .Xdefaults file? In my experience, even if every one of them is using Motif, I cannot even get the background color to change with a single line of .Xdefaults.
Not in my experience. Motif programs that have missing or corrupt .appdefault files are totally useless (like, the buttons have no labels!). I 100% agree with the initial author that these have the same problems as the windoze registry. I have never seen a Motif appdefault file that is editable, they are just "part of the program" and have to exist, unchanged from how the author wrote them.
And even if they did work, this is a horribly user-unfriendly way to customize a program!
I am not saying that you would look in the Mozilla code and see X calls. That is also stupid. What they should do is write a "toolkit", but that "toolkit" is totally dedicated to running Mozilla, and is statically linked with it, and the source code is right there with the Mozilla source code. It would provide a portability layer over the various windowing systems (on Windoze it should use WIN32 api only).
Multi-application toolkits have their uses, but on a system as large and complex as Mozilla it is much more efficient and less bug-prone to write everything at a very low level. In my experience it takes more code to interface to a toolkit when you need it to perform the slightest different than it was designed, than to just write all the gui widgets at a low level.
This was one of the reasons I created a toolkit of my own ( fltk). I tried to design it so that it could be static linked, and if you needed to make it work with your appliation, you were free to change the internal code and make it into an application-specific toolkit. I am actually rather disappointed that fltk is pretty much being used just like other toolkits, including the making of it into a shared library, which is exactly not what I intended...
I wish Mozilla all the luck in making the "Xlib" version and really look forward to seeing it. IMHO this version will be vastly superior in every way, and I do wish they would devote all their resources to it.
What are they thinking? Seems like everybody on Linux is anxious to replicate the DLL hell of Windoze.
Static linking is not evil and can actually be far more efficient. Unless you have absolute proof that a second appliation will use the functionality (not just "this is so neat of a function that somebody might want to reuse it"), please don't make a shared library!
The WIN32 API is exactly equivalent to the Xlib api. You send it letters and some other part of the code draws them. You don't draw pixels to a frame buffer.
Not that X is blameless. It is slower. This is mostly due to a bad design defect such that scrolling regions requires synchronous communication between the app and the server. This can be avoided and async scrolling implemented by nested multiple windows but most people don't know that.
I would also blame bad toolkit programming (is this a Motif program?), the assinine adding of "wide characters" to the interface, and the horrid font system inside X.
Problem with X is some bad design so that synchronous communication is required to do some things (like select colors!) and some bad programming in toolkits so that synchronous communication is done even when it is unnecessary. In this case pipes don't buy you anything, and if only one command is done between each sync then you pay for the overhead of the buffering code.
Problem was, Sun wanted to charge money for NeWS. X was free and had the source code (at the time you got it for a $100 charge for the tape). X won.
I'll let everybody draw their own conclusions about what this predicts.
Maybe we will see it someday. I think they should plan for it. This requires making a GLXcontext and an X "GC" be the same object, making OpenGL start up with an "identity" transformation that matches the X coordinates (currently it comes up undefined), and as a temporary stopgap, making all X drawing not work if the current GL transform is not the identity or if Z buffer is on (so that people don't use it and then complain later on when it does not work).
I would also like to see X *always* provide a 32-bit true color visual and fake it on the display hardware, so we could stop thinking about those stupid colormaps!
Seriously, pretty close to nothing. Do you really think somebody who would have bought a copy of Windoze would not because they can now get a "free copy compiled from the source". They can get a free copy now (just copy it off another Windoze machine), and much better and more reliable than some source compilation that may not exactly match MS's distribution, and certainly does not contain any bug fixes made since the code was stolen.
And the code can be looked at by people writing WINE, but that is illegal, the code was stolen. Nobody legit would dare go near it, in fact it is possible to see the source code now (many universities and companies have it under NDL) and using that for products is illegal as well, so there is not loss right now.
My conclusion is that stolen source code is worth almost exactly zero.
There are huge wins besides networking with getting all the graphics into it's own process and easily worth the overhead.
Best example is that they detected double clicks by waiting until the time has passed before sending a "single click" or a "double click" event to the application. This of course meant the system had a built-in delay in responding to any clicks. As an exercise to the reader, try to figure out a better interface (you have 12 seconds to answer).
Get Sun to release NeWS! Now that would be a great thing to have. It would be nice to get both the original Gosling code and the somewhat broken version which had X11 compatability.
I think this is a good indication that Free Software works. You just said somebody is making millions off it, even though others can "steal" it for free. So where is the complaint?
#2 sounds like an excellent idea.
In fact to speed it up (I think, I don't really know how the browser works) this can be a pull-down menu of levels instead of a lot of buttons, with the current setting preselected. The moderator can then pick a different setting if desired. When the scores are reported back the score is moved one point toward the score the moderator picked.
The menu should be limited to the range -1 to 10 (?). To allow numbers outside this range there could be an item "higher" that acts like 11 unless the score is already >= 11 in which case it adds one. There could also be a "lower" but I think a concrete bottom of -1 or -2 is a better idea.
kpanel -no-KDE-compliant-window-manager
How about that? It would be nice if they documented that. Actually it would be even nicer if they just detected this fact, surely they can check to see if their own window manager is running!
I wrote a window manager (flwm) and tried to get kde apps to run under it and everything seems to work except kpanel. I'll try this switch soon.