The BIOS was not a "trade secret". It was protected by copyright. The assembler listing was printed in the manual that came with the IBM PC, so it certainly was not secret!
My idea is to have the program itself use popen to talk to these other programs. Thus the only way for "cp" to make a progress meter is if it was rewritten to popen the progress meter program and talk to it. There is then no interference with stdin/stdout.
The progress bar program could certainly be aware that it is running inside a shell and do whatever is needed to display the meter in the shell (it might consist of printing escape sequences to stdout that the terminal interprets to show progress).
I do believe that the stdin/stdout communication is sufficient to communicate with a "module". However it is unlikely the streams will look like any normal stdin/out for anything other than the most trivial uses. For instance a file chooser may by default just print the chosen file on stdout, and read the currently selected file from a command line arg, but if you do anything more complicated the streams are likely to be more complicated.
As for the image preview, in most cases I have seen the file chooser likely can do a better job of preview than the program, so it would just execute the necessary program. Speed would be handled by calling a background running instance, as you suggested. If the calling program wants to display it's own data, it would register itself with the mime database or whatever, so it would be called no matter who used the file chooser.
You are right that a big problem is that the communication would be a moving target. However right now there appears to not be even *incompatable* programs. There is no command line program to act like you double-clicked on a file, for instance. Even Windows has that!
What is wanted is to have the toolkit draw the window borders and handle all the clicking in the borders.
Because the toolkit already has the code needed to make buttons and text fields and so on, I can assure you that the amount of code needed to do this is about 1/20th the size of the code you currently need to do the ICCCM communication to control the window manager (I have implemented this myself for fltk and I know what I am talking about). It would also eliminate all the slowness of resizing and moving windows (this is really latency and non-syncrhonous update, which is why increasing the speed of machines 100x has not fixed these problems on X). And if the app controlled the stacking of windows, actual floating windows would work (ie panels that remain above more than one main window) and a whole lot of GUI ideas could be done, rather than being forced to make a single big tiled window in order to avoid the window manager, which is the solution now for all Windows and most Linux programs.
Actually Windows and OS/X also have the distinction between the toolkit and the window manager. It is pretty obvious on Windows, but a little experimentation on OS/X shows that the window border is not drawn by NeXTStep but by the system.
I agree with you that it is a mistake, but they do. I actually think this is an example where X influenced their designs.
I'm pretty certain that if programs controlled all the pixels in their windows out to the edge, we would have no problems, and we would have figured out a lot more imaginative things to do that the current reserving of a whole stripe of useless pixels as the "title bar".
I am also for the option of moving some drivers into user space. (at least I think you meant moving them to user space and mistyped?)
I think this is the solution to the "stable binary API" problem. Make the user space drivers have that stable driver ABI, while in-kernel ones continue as they are today.
Most of the devices where supporting a proprietary and/or stable driver are also things that don't need the full speed of being in the kernel. So this would work out very well.
If you notice all your complaints deal with proprietary stuff and there's not much that can be done about it without reverse engineering it.
His first ones did, but I think the complaints about dual screesn and the side buttons on the mouse are legitimate. (the mouse buttons are not proprietary, since he says that messing with xorg.conf fixes them, the problem is the unwillingness to fix the X input model to support more input devices than 8 buttons and an x and y mouse position.)
I agree with your idea very much, but it does not even need to be in the shell!
It can be *programs*. Imagine there is a program called "progressbar" and you can somehow pipe cp to it or something. That's actually not a great example, but how about a program "ask..." that pops up a yes/no dialog box. And a program to pop up a file chooser, or even construct a rather complex form or dialog box and wait for the user to fill it in.
For simple use all input would be command line switches and all output would be printed to stdout by the program. More complex interaction (rather than the caller just waiting for the program to exit) would be done by using pipes to write commands to stdin and to read results back from stdout.
I believe that if the file chooser was a program that everybody called, and was easily replaced, Linux would, within 2 months, go from having the worst file choosers in the world to by far the best ones. Currently though you are stuck with the KDE/Gnome ones because there is no other way for a program to make a file chooser.
That is difficult to do if you need to run the test on a machine that does not have access to the exact rules used to normalize and match filenames. For instance if you are running on a different version of OS/X!
A file system that required that all filenames be correctly-spelled English words would be "preferable" to people too. That does not mean that implementors are so stupid that they would force this spelling corrector into the filesystem, rather than putting it somewhere intelligent such as in the GUI.
But for some reason a spelling corrector that changes 'a' to 'A' causes programmers brains to deactivate, or something, and they will actually claim that such a thing belongs in the operating system, at a very low level, where it cannot be avoided.
It is not clear what causes this delusion, but the above poster is one of the many that suffer from it.
The primary problem with case insensitivity is that it is impossible to fix the case of a filename in the obvious way (ie by using a single os mv call). You have to rename to a temporary file and rename back. Some programs such as svn really don't like this.
It also means that programs that use the wrong case to open the file will not fail, and thus lead to unexpected failures later.
There is also some security implications, the problem is that a program may make a wrong assumption about whether two different names mean the same file or not, and thus fail to protect a file. Not sure if there are real examples of this, but it is a problem. The solution is to make the test for whether two names are for different files as simple as possible, on Unix it is strcmp. On Windows and most other case-insensitive systems it is "all Unicode is case sensitive, only A-Z (and maybe the ISO-8859-1 characters) match case". On OS/X however they are using a full sting of Unicode normalization followed by elaborate tables to convert case, and it is pretty much impossible to duplicate the test without calling the system.
Unicode normalization of the filenames is also a nasty problem for similar reasons. I believe it is impossible to delete a file using the GUI that has managed to aquire a non-normalized name.
Then explain to me why it is so important to support self-signed certificates. They really are less secure than those that have been signed by a trusted third party as it's trivial to generate them on demand.
Because they are more secure than unencrypted. Yes they are vulnerable to MIM attacks, but the are NOT vulnerable to simple snooping!
Current Firefox behavior makes them look *worse* than unencrypted, which is WRONG!!!!
Really all I (and hundreds of others) want is for Firefox to accept self-signed without any comment, but not display any security indicators.
The fact that people who argue against this, without fail, always argue as though they have ignored the "not display any security indicators" part of the request, indicates to me that perhaps there are powerful forces that do not want self-signed certificates to work. I am getting stumped as to why the arguments are so illogical.
The browser could *lie* and show "http:" if that is necessary to make you happy.
Also has been suggested that it show "httpe:", that would allow cut & paste to work (as it would turn that into https when sending the url).
You could also tell people to look at the color or look for the "lock" icon. I certainly don't know of any users who look for "https", they look for the lock.
Really the arguments against this are getting silly. Self-signed should work and be treated at least as well as unencrypted pages. It does seem possible that there are powerful forces trying to get the browsers to not like self-signed certificates because the arguments for Firefox's behavior are getting really out there...
One program is resizing the windows and drawing the borders. Another program is responding to a message that the window was resized and drawing the interior. They are completely seperate programs with no synchronization (ie there is no way for one of them to wait until the other reaches a certain step).
This has been the main problem *forever* in X but it can only be fixed by scrapping window managers (well really by scrapping the part that draws the window borders). Technically there is *no* reason the application can't draw them, and it would work far, far better without any other change to X. In case you are worried about inconsistency, then using toolkits to draw them would fix that, the same way it fixes the buttons and menus and everything else to look similar to each other.
Oddly enough the first versions of X had the application draw the window borders. The problem was that there were no practical shared libraries at that time, so a "toolkit" could only be done efficiently by co-operating processes. Fortunately they did not fuck up all the buttons and so on, but they got the most important toolkit item, the window borders.
But there is more left. For example, the window manager structure. When you resize a window, first the window manager has to repaint the frame, then the client also has to repaint itself. Since they can't both repaint themselves at the same time you get flicker. The same thing applies to subwindows, check out how ugly scrollbars in gtk+ redraws when you resize their windows.
This is actually the *main* problem, not the need to redraw windows that you mentioned. MSWindows also redraws windows when you resize them and deiconize them, and double buffering (and thus the composite extension) hides any partial updates.
It is in fact the asynchronous nature of the X window manager design that is the problem. This is why a 100x increase in machine speed has not hidden the problem, it is just as bad as it was 20 years ago.
The easiest proof is to see that programs that draw their own window borders, such as a lot of music players, resize and redraw quite smooth on the same X server where resizes are bad for other programs.
Unfortunatly fixing this means scrapping the "window manager" and there are a lot of people religeously opposed to that idea. They will say "oh the window borders will look different and that will *confuse* the user! Horrors!" (yet for some reason this is not a problem for every detail *inside* the window, which is drawn by the program, and for some reason the solution for those (using a toolkit) does not work for window borders.
You are thinking of NeWS, which is not at all Display Postscript. NeWS did expect all the widgets to be written in PostScript and sent to the server.
NeWS was a really neat idea at the time.
The graphics capabilities are still better than anything today. For instance you could create a window from a PostScript path, and thus create a window with holes or disconnected pieces. The windows also carried a CTM so you could scale the interface arbitrarily without the program knowing. And in 1985 you could scale and rotate fonts arbitrarily (though there was no antialiasing), and scale and rotate images.
Slashdot Mirror
This is the first post here that makes sense!
You are right, the illegal thing being done is *copying* the software, whether they modified it or not.
The BIOS was not a "trade secret". It was protected by copyright. The assembler listing was printed in the manual that came with the IBM PC, so it certainly was not secret!
No I'm just mistakenly thinking NetworkManager was a Ubuntu-only thing. Is it Debian-only?
My idea is to have the program itself use popen to talk to these other programs. Thus the only way for "cp" to make a progress meter is if it was rewritten to popen the progress meter program and talk to it. There is then no interference with stdin/stdout.
The progress bar program could certainly be aware that it is running inside a shell and do whatever is needed to display the meter in the shell (it might consist of printing escape sequences to stdout that the terminal interprets to show progress).
I do believe that the stdin/stdout communication is sufficient to communicate with a "module". However it is unlikely the streams will look like any normal stdin/out for anything other than the most trivial uses. For instance a file chooser may by default just print the chosen file on stdout, and read the currently selected file from a command line arg, but if you do anything more complicated the streams are likely to be more complicated.
As for the image preview, in most cases I have seen the file chooser likely can do a better job of preview than the program, so it would just execute the necessary program. Speed would be handled by calling a background running instance, as you suggested. If the calling program wants to display it's own data, it would register itself with the mime database or whatever, so it would be called no matter who used the file chooser.
You are right that a big problem is that the communication would be a moving target. However right now there appears to not be even *incompatable* programs. There is no command line program to act like you double-clicked on a file, for instance. Even Windows has that!
What is wanted is to have the toolkit draw the window borders and handle all the clicking in the borders.
Because the toolkit already has the code needed to make buttons and text fields and so on, I can assure you that the amount of code needed to do this is about 1/20th the size of the code you currently need to do the ICCCM communication to control the window manager (I have implemented this myself for fltk and I know what I am talking about). It would also eliminate all the slowness of resizing and moving windows (this is really latency and non-syncrhonous update, which is why increasing the speed of machines 100x has not fixed these problems on X). And if the app controlled the stacking of windows, actual floating windows would work (ie panels that remain above more than one main window) and a whole lot of GUI ideas could be done, rather than being forced to make a single big tiled window in order to avoid the window manager, which is the solution now for all Windows and most Linux programs.
Actually Windows and OS/X also have the distinction between the toolkit and the window manager. It is pretty obvious on Windows, but a little experimentation on OS/X shows that the window border is not drawn by NeXTStep but by the system.
I agree with you that it is a mistake, but they do. I actually think this is an example where X influenced their designs.
I'm pretty certain that if programs controlled all the pixels in their windows out to the edge, we would have no problems, and we would have figured out a lot more imaginative things to do that the current reserving of a whole stripe of useless pixels as the "title bar".
I am also for the option of moving some drivers into user space. (at least I think you meant moving them to user space and mistyped?)
I think this is the solution to the "stable binary API" problem. Make the user space drivers have that stable driver ABI, while in-kernel ones continue as they are today.
Most of the devices where supporting a proprietary and/or stable driver are also things that don't need the full speed of being in the kernel. So this would work out very well.
If you notice all your complaints deal with proprietary stuff and there's not much that can be done about it without reverse engineering it.
His first ones did, but I think the complaints about dual screesn and the side buttons on the mouse are legitimate. (the mouse buttons are not proprietary, since he says that messing with xorg.conf fixes them, the problem is the unwillingness to fix the X input model to support more input devices than 8 buttons and an x and y mouse position.)
I think the existence of NetworkManager implies he is running Ubuntu.
I agree with your idea very much, but it does not even need to be in the shell!
It can be *programs*. Imagine there is a program called "progressbar" and you can somehow pipe cp to it or something. That's actually not a great example, but how about a program "ask ..." that pops up a yes/no dialog box. And a program to pop up a file chooser, or even construct a rather complex form or dialog box and wait for the user to fill it in.
For simple use all input would be command line switches and all output would be printed to stdout by the program. More complex interaction (rather than the caller just waiting for the program to exit) would be done by using pipes to write commands to stdin and to read results back from stdout.
I believe that if the file chooser was a program that everybody called, and was easily replaced, Linux would, within 2 months, go from having the worst file choosers in the world to by far the best ones. Currently though you are stuck with the KDE/Gnome ones because there is no other way for a program to make a file chooser.
That is difficult to do if you need to run the test on a machine that does not have access to the exact rules used to normalize and match filenames. For instance if you are running on a different version of OS/X!
Both Windows and Linux, and I'm pretty certain OS/X as well, do this.
A file system that required that all filenames be correctly-spelled English words would be "preferable" to people too. That does not mean that implementors are so stupid that they would force this spelling corrector into the filesystem, rather than putting it somewhere intelligent such as in the GUI.
But for some reason a spelling corrector that changes 'a' to 'A' causes programmers brains to deactivate, or something, and they will actually claim that such a thing belongs in the operating system, at a very low level, where it cannot be avoided.
It is not clear what causes this delusion, but the above poster is one of the many that suffer from it.
The primary problem with case insensitivity is that it is impossible to fix the case of a filename in the obvious way (ie by using a single os mv call). You have to rename to a temporary file and rename back. Some programs such as svn really don't like this.
It also means that programs that use the wrong case to open the file will not fail, and thus lead to unexpected failures later.
There is also some security implications, the problem is that a program may make a wrong assumption about whether two different names mean the same file or not, and thus fail to protect a file. Not sure if there are real examples of this, but it is a problem. The solution is to make the test for whether two names are for different files as simple as possible, on Unix it is strcmp. On Windows and most other case-insensitive systems it is "all Unicode is case sensitive, only A-Z (and maybe the ISO-8859-1 characters) match case". On OS/X however they are using a full sting of Unicode normalization followed by elaborate tables to convert case, and it is pretty much impossible to duplicate the test without calling the system.
Unicode normalization of the filenames is also a nasty problem for similar reasons. I believe it is impossible to delete a file using the GUI that has managed to aquire a non-normalized name.
Considering people are still saying Al Gore created the Internet, I don't think it will be over for awhile.
I laughed at Colbert's version: because of the International Date Line, not only can she see Russia, she can *see into the Future!*.
Then explain to me why it is so important to support self-signed certificates. They really are less secure than those that have been signed by a trusted third party as it's trivial to generate them on demand.
Because they are more secure than unencrypted. Yes they are vulnerable to MIM attacks, but the are NOT vulnerable to simple snooping!
Current Firefox behavior makes them look *worse* than unencrypted, which is WRONG!!!!
Really all I (and hundreds of others) want is for Firefox to accept self-signed without any comment, but not display any security indicators.
The fact that people who argue against this, without fail, always argue as though they have ignored the "not display any security indicators" part of the request, indicates to me that perhaps there are powerful forces that do not want self-signed certificates to work. I am getting stumped as to why the arguments are so illogical.
The browser could *lie* and show "http:" if that is necessary to make you happy.
Also has been suggested that it show "httpe:", that would allow cut & paste to work (as it would turn that into https when sending the url).
You could also tell people to look at the color or look for the "lock" icon. I certainly don't know of any users who look for "https", they look for the lock.
Really the arguments against this are getting silly. Self-signed should work and be treated at least as well as unencrypted pages. It does seem possible that there are powerful forces trying to get the browsers to not like self-signed certificates because the arguments for Firefox's behavior are getting really out there...
The problem is the asynchronous window manager.
One program is resizing the windows and drawing the borders. Another program is responding to a message that the window was resized and drawing the interior. They are completely seperate programs with no synchronization (ie there is no way for one of them to wait until the other reaches a certain step).
This has been the main problem *forever* in X but it can only be fixed by scrapping window managers (well really by scrapping the part that draws the window borders). Technically there is *no* reason the application can't draw them, and it would work far, far better without any other change to X. In case you are worried about inconsistency, then using toolkits to draw them would fix that, the same way it fixes the buttons and menus and everything else to look similar to each other.
Oddly enough the first versions of X had the application draw the window borders. The problem was that there were no practical shared libraries at that time, so a "toolkit" could only be done efficiently by co-operating processes. Fortunately they did not fuck up all the buttons and so on, but they got the most important toolkit item, the window borders.
But there is more left. For example, the window manager structure. When you resize a window, first the window manager has to repaint the frame, then the client also has to repaint itself. Since they can't both repaint themselves at the same time you get flicker. The same thing applies to subwindows, check out how ugly scrollbars in gtk+ redraws when you resize their windows.
This is actually the *main* problem, not the need to redraw windows that you mentioned. MSWindows also redraws windows when you resize them and deiconize them, and double buffering (and thus the composite extension) hides any partial updates.
It is in fact the asynchronous nature of the X window manager design that is the problem. This is why a 100x increase in machine speed has not hidden the problem, it is just as bad as it was 20 years ago.
The easiest proof is to see that programs that draw their own window borders, such as a lot of music players, resize and redraw quite smooth on the same X server where resizes are bad for other programs.
Unfortunatly fixing this means scrapping the "window manager" and there are a lot of people religeously opposed to that idea. They will say "oh the window borders will look different and that will *confuse* the user! Horrors!" (yet for some reason this is not a problem for every detail *inside* the window, which is drawn by the program, and for some reason the solution for those (using a toolkit) does not work for window borders.
"Pixmaps" in xlib *are* on the server. That actually is what that symbol means.
Lots of programs dump a lot of pixmaps to the server on startup.
I think actually NX is *avoiding* sending the pixmap to the server until it is actually used, and is compressing them.
Yes this is exactly the solution that can be used.
How can rendering the font on the client and sending it to the server as a bitmap result in fewer roundtrips between client and server?
Because if you look at a real program you will find that there are about 10 times as many calls to "measure" the letters than to actually draw them.
In addition the "measure" api is synchronous (because it returns some information) so it cannot be streamed.
The overhead of sending a small picture in a stream verses a glyph number is actually pretty minor.
In addition the images are cached on the server, so each letter is sent only once.
You are thinking of NeWS, which is not at all Display Postscript. NeWS did expect all the widgets to be written in PostScript and sent to the server.
NeWS was a really neat idea at the time.
The graphics capabilities are still better than anything today. For instance you could create a window from a PostScript path, and thus create a window with holes or disconnected pieces. The windows also carried a CTM so you could scale the interface arbitrarily without the program knowing. And in 1985 you could scale and rotate fonts arbitrarily (though there was no antialiasing), and scale and rotate images.
Then another api can be added for some nice generic version of that bit depth (such as float), but the 32-bit api would continue to work.
What I want to get rid of is this bullshit where the program has to figure out how to convert it's drawing to all types of image bitmaps.