There seems to be lots of objections that this will "break Posix compatability". Yet nobody seems to worry about the fact that Linux can read FAT32 or NTFS or all those distributed file system experiments or Samba shares, or adding ACL to the file systems, or changing the size of devt and inode numbers. I'm sure all those break posix. For instance opening "foo" and "FOO" on my FAT32 partition at the same time breaks Posix rules. Yet we don't see programs crashing all the time when they access a Windows disk.
The fact is that I want to be able to say "cat http://slashdot.org > file" and it should work without cat having to be recompiled. The fact that this is not true should be embarassing for a system designed to continue the Unix tradition.
People also complain that it will need hundreds of calls. That is wrong, nobody is saying a program *has* to use this interface. If your browser knows how to do something smarter than open()/read() when it gets the string "http://slashdot.org" nothing is stopping it from doing it's own implementation!
I agree with the orignal poster. Adding VFS to the kernel is the number one priority for getting Linux out of the dark ages. This is also one of the few places where desktop usability absolutlely requires kernel work. So why isn't this being done?
Microsoft Terminal Services does not work at the toolkit level, it works at the GDI32 level. Otherwise it would be useless for 90% of the programs out there, including Word, all of which bypass MFC and the Win32 toolkit in order to draw things at a lower level.
Yes X is slow because lots of programs send bitmaps, but it does this because of the lousy rendering model, where the desired picture can only be communicated as a bitmap. Not because of the toolkit. People who claim this are mistaken: a button might be "draw a box and draw this text as a label". If you actually believe the interface to the X_Toolkit_Button object is smaller and leaner than that you really should study programming a bit more, perhaps write a real application.
It seems the fastest scheme may be VNC-like, with some minimal support from the system so that the area that is changed, and when it finished changing, can be more clearly identified.
X actually has the exact same mechanism as Windows for the clipboard, it's just that the ICCCM morons failed to assign any token other than ASCII text. Even the first version of windows had numerical ids for BMP and RTF, and programmers were thus able to find some sample data to cut & paste and do at least a minimal amount of work to interpret the received data. On X it was impossible to even produce a sample piece of data.
However I think now the solution is to ignore the entire mess. It looks like a better solution is to use url's to name the data, and a vfs to get it. This allows a program to reuse it's file read/write code, which is probably tested a lot more and much more robust.
The types could be completely eliminated by having all applications assumme the clipboard contents is a UTF-8 encoded string. If there is a colon near the start it is a url, and the program must open that file and read the data (drag & drop would be done by writing the data to a temporary ram fs). Otherwise it is UTF-8 text. Programs that don't understand url's can just paste the text including the colon, this will allow urls to be cut/pasted from mail and terminals. Possibly some simple RTF could be done with imbedded control characters (ie ^B for bold...) though I am unsure if that is a good idea, it is suprising how few programs even on Windows copy formatting.
I think the innovation is that a single key temporarily minaturizes all your windows, and exiting this mode puts them all back. You would have to click on each window in turn to get the same effect on AIX.
Of course the public now is too dazed by graphics to be able to tell what is really innovative. Showing the window in a smaller version is an OLD idea, in fact the original designs of windowing systems in the 70's assummed this would be what iconized windows look like.
If you are describing really what you think is "innovative" about Expose, then you have also declared that you don't think this is a copy. This Metacity thing is NOT scaling the live contents of the windows (X without the proposed compositing extension is incapable of this), thus bypassing what you are claiming is the innovation.
I believe the innovation is to have a single key that temporarily "iconizes" all the windows to thumbnails. On some older (pre-X) systems you could iconize each window by hand and the icon was a thumbnail of the window, you could then rearrange them to not overlap and then open one.
Yes I would say that Metacity has copied this idea.
Expose is pretty trivial to implement if KP's compositing extension is in X. What I am suprised is that they were able to do this without the extension, I think this is really clever (dare I say "innovative") and would not have believed it is possible. All I can guess is that they are taking snapshots when the window manager knows windows are unobscured.
I would say the fact that they figured out how to do this without rewriting the window system to have off-screen buffers is pretty innovative. It is very possible Apple thought of this idea before OS/X but quickly said it was impossible without the offscreen rendering and the compositing of windows. It would appear this could have worked on X 10 years ago (and perhaps on Windows too) but nobody thought it possible.
Every window under the M$ GUI--even when running my old DOS text editor--has largely-usable (won't scroll, but hey) Mark/Copy/Paste icons attached to the window.
I have never seen this. Start/Run/"command.exe" produced an 80x24 line window with no buttons.
Besides it is not ctrl+x and ctrl+v. Are you seriously saying that if some (not all) Linux programs put buttons marked "copy" and "paste" on the window border, it would be user friendly?
The machines could overwrite their software with a clean version when they turn in the final tally. Or they could respond to outside requests to change their tally and that would not be discovered unless somebody accidentally sent this cryptic request. Or the numbers may be changed at the central location and not by the machine.
That type of fraud is miniscule compared to a fraud where the voting machine switches every 100th vote to the desired candidate. This is the type of fraud that is being feared with these machines.
When I withdraw money from an ATM, I get proof that it worked. I recieve a "paper trail" in the form of 20 doller bills, that I can verify add up to the sum I intended to withdraw. I also get a statement later on indicating the amount I withdrew and can verify that.
The serious fear is that people that are supposed to be controlling the machines will tamper with them. Not "hackers".
Unfortunately the average public is too stupid to realize that a company making a machine may actually be evil. No criminal is ever shown in popular entertainment to ever have a paying job, and certainly is never shown using their paying job to commit a crime.
Actually XFree86 pretends to support multiple visuals (currently on my Matrox card it's reporting 8, 4 TrueColor and 4 DirectColor) but the implementation is broken
The direct color visual is because the card supports per-channel lookup tables (ie a 256-entry table for red, another for green, and another for blue). The only practical use for this is for gamma adjustment, but most hardware is broken in that it only supports 8-bit entries in the table, making any setting other than the identity useless because at least 2 colors will map to the same value. As you probably know, such tables are useless for "blinking pixels" or any other use. Once upon a time they were used for fast preview of color corrections, which is similar to what you are requesting, but that is not usable for modern painting programs where most corrections are not color-independent and thus the programmers time is better served figuring out how to update the whole picture directly than to try to use this, also most users are annoyed when the entire GUI changes color when adjusting their photo's correction.
The reason TrueColor is reported as well as DirectColor is because of programs that only look for TrueColor. On XFree86 if you mess with the DirectColor lookup table you will also change the TrueColor lookup, which is not what the design of X intended.
Again I feel X's design is just WRONG. It could report *only* TrueColor, and have a seperate call for "change the color lookup" which could also accept an arbitrary-sized set of points that it interpolates, so you don't need to know how many bits per pixel are stored. This call could return failure if the hardware cannot do it.
The reason there are 4 of each visual is for GLX. Due, again, to stupid design, the only method of communicating how a window was set up from GLX is to change the visual number, so GLX needs to use this to send what buffers are enabled to X. Most likely these visuals correspond to whether a back buffer is enabled and whether an alpha buffer is enabled, on my Irix machine there are 64 copies of each visual, indicating 8 on/off selectors. Again all obsolete on modern machines, where it would probably be most efficient to turn on all buffers all the time.
Re:While we're in punditry mode ...
on
Linux in 2004?
·
· Score: 1
I expect the differences will be gradually merged until you cannot really tell which one is running.
The huge advantage here is that it works as a great filter so only features that are needed for interoperability will be put into the "low level" desktop interface. Meanwhile behavior features that do not need to be looked at by other programs will remain in the per-toolkit area, where they should be.
This is similar to getting rid of the text/data distinction in files. On older pre-Multics systems there were hundreds of calls to manage records and databases in files (this is pretty much where Windows is, and where you would be if you wrote to QT or GTK only). The only alternative anybody saw was to let programs write the disk blocks directly (pretty much the equivalent of Xlib now) so you could only use one program on a machine (like where Gnome and KDE conflict). When Multics/Unix came out, they managed to reduce the system interface to the open/seek/read/write we all use now. More complex interfaces (like SQL) can be built on top of this, and many alternatives used at the same time without conflict. Also things like networked storage, undreamed of at the time this interface was invented, are possible.
I do hope that having these conflicts will force the GUI interface toward a logical and minimal design. It is difficult, but much preferrable to having a baroque Windows (or KDE or Gnome) interface only.
Re:Two things that need to happen in 2004
on
Linux in 2004?
·
· Score: 1
Okay, here is an actual, concrete, "desktop navigation" idea that I really want to see implemented. It will not "confuse users", it is simple, and it will make use of multiple programs on the desktop 100 times easier than it is on Windows:
STOP RAISING WINDOWS ON CLICK!!!!
The ONLY way the window manager should change the order of windows is if the user clicks the title bar of the window, or if they click the title bar (and thus raise) a "parent" (transient-for) window. Alt-tab style navigation and other ways of navigating to the window can also raise it.
Do NOT raise the window when the user clicks inside the contents. Do not raise it when the user resizes it. Do not raise a window because a "child" (the one with transient-for set) is raised (this one is a bug in virtually every window manager that exists today).
Anybody who says "but that will be inconsistent and confuse the poor user" has to get through their thick heads: the application can raise itself in response to a click. In fact X toolkits already do this. All I want is the ability for an application to intuitively decide if the user is not switching their entire focus to the application and not raise it. The current Windows and Linux design do not allow this behavior.
This is vital so that the gui is usable for more than one document that takes more than half the screen, where you have to overlap the windows. Right now this is useless and forces applications (on both Linux and Windows) to use "tiled" arrangments with great amounts of unfriendly scrolling and scaling of the displayed data. Actual tiled window systems were soundly rejected (the original Andrew did this, and Microsoft tried it with their first versions of Windows), so the fact that people are using "tiled" inside applications should be a sign that something is wrong.
The latest window managers for Linux seem to have completely lost the ability to act this way (at best it makes it so you cannot raise a window at all, even by clicking the title bar). Every single window manager since CDE has had the bug where raising a child window also raises it's parent. PLEASE fix this!
And don't say "use your own window manager". That is not going to help when the majority are using a broken one.
Copy & paste works. You use ctrl+x and ctrl+v to do it. These are the same keys as in most Windows programs. The only program of importance where it does not work is the terminal emulator, where it doesn't work on Windows, either!
(There is also the middle-mouse "drag & drop" which was put into X to make it usable for terminals. Even the first version of X was designed to do clipboard operations, through "Cut Buffers". It appears the middle-mouse is really quite convienent, and also the fact that it was the only thing that worked in the terminal, led a lot of people, including programmers, to think it is the only mechanism available. This made some people (including me) to try to emulate ctrl+x/v by using the same buffer as the middle mouse, leading to the broken behavior about 5 years ago (it would have been better to have clipboard not work at all). However this has been corrected in all modern programs and toolkits)
This endless repetition of "copy and paste" indicates to me that a number of posts out there are working off a script. There certainly are problems with the Linux desktop, but plain "copy and paste" is not one of them, especially to a "new user" who would never even figure out how to run a program old enough to not have copy and paste (the complaint is similar to complaining that copy and paste does not work on Windows when you run Lotus 123). The endless repetition of this statement plus the apparent inability of the same posters to name any other problem leads me to believe that this is scripted by non-Linux users.
Hint for the scripted posters: you can update the script to say "copy and paste anything other than text". This is an area where Windows is certainly better, mostly because the morons working on X built a mechanism but refused to assign a few predefined numbers to mean "an image" or "rich text".
Re:Gentoo, Portage, Python
on
Linux in 2004?
·
· Score: 2, Insightful
I would think most of the theoretical advantages with compiling packages yourself is not from different -O settings, but because #if statements inside the code may completely eliminate parts of it at compile time. For instance compiling out support for some back-compatability thing you don't have or use may speed up a program, and will certainly make it smaller.
This is all in theory, however. I am unsure if there is any reason for it. If machines get fast enough that people don't mind a compile as part of install then I see no reason not to distribute source-only. But the only definate advantage is the fact that the thing you download is far more likely to work, I am unsure if there would be performance advantages.
All very clever and it sounds like he knows what he is talking about.
However perhaps he should examing exactly how those new-fangled high-speed hardware boards work. Maybe examine how geometry is sent to them nowadays. Take a look at how those fragment/pixel shaders are stored and sent to the card. Take a look at how they get operations to happen on vertical retrace.
Hint: it looks a LOT like a stream. And this is designed by people who are desperate to get them to run as fast as possible.
You might also check why disk interfaces are going serial, and even the main bus may go serial someday.
"*bufferptr++ = x" is faster than any call, and can be easily parallelized. Also memcpy is much, much faster when you have a block of already-composed graphics. And if you studied it at all you would see that at least 90% of the operations a program do is "copy this precomposed graphic (which could be a letter or glyph) from memory to the device".
Just to be technical, pure "latency" is not the problem with X. You would be suprised at how easily you could use a machine where the display updated fast, but was delayed 1 second from anything you did. Shooting games might be difficult, but a lot of bad word form-filling software and the web work this way.
The round-trips are made bad by latency, but the real problem is that they require 2 whole latency steps for every call. Even a microsecond makes the display draw unbearably slow. Non-round-trip calls can be shoved down a pipe and thus hundreds of thousands can be sent in a second even if there is a second of "latency".
Even making a "DRI" interface, as is often suggested, will not help, as it still means a good number of machine instructions, pushing and popping, are done each call. Some misguided other posters seem to thing "marshalling" and "unmarshalling" are expensive, they are wrong. Ever wonder why things like "display lists" are used to make 3D hardware run fast?
Although using the rewritten Xlib interface will not be any faster, this will allow you to use the XCB interface as well, and perhaps gradually modify your program to 100% XCB.
I have not read the papers in quite awile, but the main reason XCB is faster is that it is a direct interface to the X wire protocol. If some Xlib call was something like "send message x", "wait for response x", in XCB these are two calls. The advantage is that you can do a lot of other stuff, such as sending other messages, between the send and the wait for response. In some cases this can turn the client-server model from a liability into a huge benifit.
Perhaps you are using old framebuffer programs? Try Alt+F7 to switch back to X. But really I have not seen any of these lately. Any program wanting OpenGL is now better off using X.
You are seriously deluded about how much computing power is needed to change the pixels on the screen. A typical game now is changing the color of EVERY SINGLE PIXEL, up to 80 TIMES A SECOND, and is doing a much more complicated operation that just filling a shape with a constant.
Also it should be obvious that any of the symbolic graphics you are talking about can be drawn on a full-color display. The fact that many pixels have the same color does not mean that a colormap is required.
I have programmed with colormaps with cells reserved for "blink". I have also used sprites and overlay planes. Yes I can see why these were created, but I can also state with absolute conviction that I am glad they are gone.
The only reason Colormaps survived so long in X is because of the absurd design so that a colormapped machine could not pretend to be full-color. Windows (much to Unix's embarassment) at least made the true-color calls work and produce ugly dithering on colormapped displays. The result was that every program was rewritten quickly to not require colormaps because it was so vastly easier to use the true-color settings, and it soon became far more likely to find a full-color display used on Windows than on X. It was not until XFree86 with it's one-visual-only design that Linux displays caught up.
Re:What will drive Linux adoption
on
Linux in 2004?
·
· Score: 4, Insightful
No. There seems to be this big delusion that somehow OpenSource has to rewrite virtually every commercial application.
Maybe commercial companies will port to Linux!! Oh no, you say, isn't that illegal by RMS's communist manifesto? Sorry to break your fantasy, but it is legal, only Microsoft wants you to believe otherwise.
Take a look at the special effects industry and you will see that there is lots of commercial, closed-source, for-profit software being written for Linux.
PS: What Linux really needs is to be pre-installed on machines in a store. However it appears that Microsoft is still disallowing dual-boot machines to be sold.
The wording here is really a bit too strange and not like a normal Microsoft attack. First of all anybody with any knowledge of history would put the "rock solid" joke on ME, not 95. And I never heard the "just for ME!" line before, in fact this is pronounce emm-e by every Microsoft hater. Though the background of XP is obvious teletubbies appearance, most Microsoft haters attack the candy-coloring bubbles which don't resemble Teletubbies scenery much at all. And "the radiator would dislodge?" How about "when you go over a bump it would stall" or otherwise do an obvious failure.
It should be obvious that Microsoft is setting this up. They want to attack OSS on security. Their plan is to put a hole or exploit into the code by compromising some system to infect the code. Possibly this has been caught three times now, but there may be a missed one already planted, so everybody check carefully! Notice that they plan to announce this "security" stuff apparently in sync with 2.6 being released.
The far easier way to plant a hole in Linux would be to pay off or threaten some developer to do it. However they cannot do this because of the obvious fact that this can be done to one of their employees as well. They have to do it by "hacking" and they need to print this paper to show that they are extremely well-protected against "hacking", while open-source is "vulnerable"
The several posts like this, which seem out of character (ie treating Microsoft as childish rather than a threatening if clumsy evil), I think are planted. They want to point out that this coming failure of open-source has nothing to do with the security of the software on your desktop, but everything to do with the fact that people can work on the code.
Slashdot Mirror
I don't understand this at all.
There seems to be lots of objections that this will "break Posix compatability". Yet nobody seems to worry about the fact that Linux can read FAT32 or NTFS or all those distributed file system experiments or Samba shares, or adding ACL to the file systems, or changing the size of devt and inode numbers. I'm sure all those break posix. For instance opening "foo" and "FOO" on my FAT32 partition at the same time breaks Posix rules. Yet we don't see programs crashing all the time when they access a Windows disk.
The fact is that I want to be able to say "cat http://slashdot.org > file" and it should work without cat having to be recompiled. The fact that this is not true should be embarassing for a system designed to continue the Unix tradition.
People also complain that it will need hundreds of calls. That is wrong, nobody is saying a program *has* to use this interface. If your browser knows how to do something smarter than open()/read() when it gets the string "http://slashdot.org" nothing is stopping it from doing it's own implementation!
I agree with the orignal poster. Adding VFS to the kernel is the number one priority for getting Linux out of the dark ages. This is also one of the few places where desktop usability absolutlely requires kernel work. So why isn't this being done?
Microsoft Terminal Services does not work at the toolkit level, it works at the GDI32 level. Otherwise it would be useless for 90% of the programs out there, including Word, all of which bypass MFC and the Win32 toolkit in order to draw things at a lower level.
Yes X is slow because lots of programs send bitmaps, but it does this because of the lousy rendering model, where the desired picture can only be communicated as a bitmap. Not because of the toolkit. People who claim this are mistaken: a button might be "draw a box and draw this text as a label". If you actually believe the interface to the X_Toolkit_Button object is smaller and leaner than that you really should study programming a bit more, perhaps write a real application.
It seems the fastest scheme may be VNC-like, with some minimal support from the system so that the area that is changed, and when it finished changing, can be more clearly identified.
X actually has the exact same mechanism as Windows for the clipboard, it's just that the ICCCM morons failed to assign any token other than ASCII text. Even the first version of windows had numerical ids for BMP and RTF, and programmers were thus able to find some sample data to cut & paste and do at least a minimal amount of work to interpret the received data. On X it was impossible to even produce a sample piece of data.
However I think now the solution is to ignore the entire mess. It looks like a better solution is to use url's to name the data, and a vfs to get it. This allows a program to reuse it's file read/write code, which is probably tested a lot more and much more robust.
The types could be completely eliminated by having all applications assumme the clipboard contents is a UTF-8 encoded string. If there is a colon near the start it is a url, and the program must open that file and read the data (drag & drop would be done by writing the data to a temporary ram fs). Otherwise it is UTF-8 text. Programs that don't understand url's can just paste the text including the colon, this will allow urls to be cut/pasted from mail and terminals. Possibly some simple RTF could be done with imbedded control characters (ie ^B for bold...) though I am unsure if that is a good idea, it is suprising how few programs even on Windows copy formatting.
I think the innovation is that a single key temporarily minaturizes all your windows, and exiting this mode puts them all back. You would have to click on each window in turn to get the same effect on AIX.
Of course the public now is too dazed by graphics to be able to tell what is really innovative. Showing the window in a smaller version is an OLD idea, in fact the original designs of windowing systems in the 70's assummed this would be what iconized windows look like.
More accuratley it needs precisely what is in the proposed Compositing extension, which (perhaps unfortunatly) does not require OpenGL.
If you are describing really what you think is "innovative" about Expose, then you have also declared that you don't think this is a copy. This Metacity thing is NOT scaling the live contents of the windows (X without the proposed compositing extension is incapable of this), thus bypassing what you are claiming is the innovation.
I believe the innovation is to have a single key that temporarily "iconizes" all the windows to thumbnails. On some older (pre-X) systems you could iconize each window by hand and the icon was a thumbnail of the window, you could then rearrange them to not overlap and then open one.
Yes I would say that Metacity has copied this idea.
Expose is pretty trivial to implement if KP's compositing extension is in X. What I am suprised is that they were able to do this without the extension, I think this is really clever (dare I say "innovative") and would not have believed it is possible. All I can guess is that they are taking snapshots when the window manager knows windows are unobscured.
I would say the fact that they figured out how to do this without rewriting the window system to have off-screen buffers is pretty innovative. It is very possible Apple thought of this idea before OS/X but quickly said it was impossible without the offscreen rendering and the compositing of windows. It would appear this could have worked on X 10 years ago (and perhaps on Windows too) but nobody thought it possible.
Every window under the M$ GUI--even when running my old DOS text editor--has largely-usable (won't scroll, but hey) Mark/Copy/Paste icons attached to the window.
I have never seen this. Start/Run/"command.exe" produced an 80x24 line window with no buttons.
Besides it is not ctrl+x and ctrl+v. Are you seriously saying that if some (not all) Linux programs put buttons marked "copy" and "paste" on the window border, it would be user friendly?
The machines could overwrite their software with a clean version when they turn in the final tally. Or they could respond to outside requests to change their tally and that would not be discovered unless somebody accidentally sent this cryptic request. Or the numbers may be changed at the central location and not by the machine.
That type of fraud is miniscule compared to a fraud where the voting machine switches every 100th vote to the desired candidate. This is the type of fraud that is being feared with these machines.
When I withdraw money from an ATM, I get proof that it worked. I recieve a "paper trail" in the form of 20 doller bills, that I can verify add up to the sum I intended to withdraw. I also get a statement later on indicating the amount I withdrew and can verify that.
The serious fear is that people that are supposed to be controlling the machines will tamper with them. Not "hackers".
Unfortunately the average public is too stupid to realize that a company making a machine may actually be evil. No criminal is ever shown in popular entertainment to ever have a paying job, and certainly is never shown using their paying job to commit a crime.
Actually XFree86 pretends to support multiple visuals (currently on my Matrox card it's reporting 8, 4 TrueColor and 4 DirectColor) but the implementation is broken
The direct color visual is because the card supports per-channel lookup tables (ie a 256-entry table for red, another for green, and another for blue). The only practical use for this is for gamma adjustment, but most hardware is broken in that it only supports 8-bit entries in the table, making any setting other than the identity useless because at least 2 colors will map to the same value. As you probably know, such tables are useless for "blinking pixels" or any other use. Once upon a time they were used for fast preview of color corrections, which is similar to what you are requesting, but that is not usable for modern painting programs where most corrections are not color-independent and thus the programmers time is better served figuring out how to update the whole picture directly than to try to use this, also most users are annoyed when the entire GUI changes color when adjusting their photo's correction.
The reason TrueColor is reported as well as DirectColor is because of programs that only look for TrueColor. On XFree86 if you mess with the DirectColor lookup table you will also change the TrueColor lookup, which is not what the design of X intended.
Again I feel X's design is just WRONG. It could report *only* TrueColor, and have a seperate call for "change the color lookup" which could also accept an arbitrary-sized set of points that it interpolates, so you don't need to know how many bits per pixel are stored. This call could return failure if the hardware cannot do it.
The reason there are 4 of each visual is for GLX. Due, again, to stupid design, the only method of communicating how a window was set up from GLX is to change the visual number, so GLX needs to use this to send what buffers are enabled to X. Most likely these visuals correspond to whether a back buffer is enabled and whether an alpha buffer is enabled, on my Irix machine there are 64 copies of each visual, indicating 8 on/off selectors. Again all obsolete on modern machines, where it would probably be most efficient to turn on all buffers all the time.
I expect the differences will be gradually merged until you cannot really tell which one is running.
The huge advantage here is that it works as a great filter so only features that are needed for interoperability will be put into the "low level" desktop interface. Meanwhile behavior features that do not need to be looked at by other programs will remain in the per-toolkit area, where they should be.
This is similar to getting rid of the text/data distinction in files. On older pre-Multics systems there were hundreds of calls to manage records and databases in files (this is pretty much where Windows is, and where you would be if you wrote to QT or GTK only). The only alternative anybody saw was to let programs write the disk blocks directly (pretty much the equivalent of Xlib now) so you could only use one program on a machine (like where Gnome and KDE conflict). When Multics/Unix came out, they managed to reduce the system interface to the open/seek/read/write we all use now. More complex interfaces (like SQL) can be built on top of this, and many alternatives used at the same time without conflict. Also things like networked storage, undreamed of at the time this interface was invented, are possible.
I do hope that having these conflicts will force the GUI interface toward a logical and minimal design. It is difficult, but much preferrable to having a baroque Windows (or KDE or Gnome) interface only.
STOP RAISING WINDOWS ON CLICK!!!!
The ONLY way the window manager should change the order of windows is if the user clicks the title bar of the window, or if they click the title bar (and thus raise) a "parent" (transient-for) window. Alt-tab style navigation and other ways of navigating to the window can also raise it.
Do NOT raise the window when the user clicks inside the contents. Do not raise it when the user resizes it. Do not raise a window because a "child" (the one with transient-for set) is raised (this one is a bug in virtually every window manager that exists today).
Anybody who says "but that will be inconsistent and confuse the poor user" has to get through their thick heads: the application can raise itself in response to a click. In fact X toolkits already do this. All I want is the ability for an application to intuitively decide if the user is not switching their entire focus to the application and not raise it. The current Windows and Linux design do not allow this behavior.
This is vital so that the gui is usable for more than one document that takes more than half the screen, where you have to overlap the windows. Right now this is useless and forces applications (on both Linux and Windows) to use "tiled" arrangments with great amounts of unfriendly scrolling and scaling of the displayed data. Actual tiled window systems were soundly rejected (the original Andrew did this, and Microsoft tried it with their first versions of Windows), so the fact that people are using "tiled" inside applications should be a sign that something is wrong.
The latest window managers for Linux seem to have completely lost the ability to act this way (at best it makes it so you cannot raise a window at all, even by clicking the title bar). Every single window manager since CDE has had the bug where raising a child window also raises it's parent. PLEASE fix this!
And don't say "use your own window manager". That is not going to help when the majority are using a broken one.
Copy & paste works. You use ctrl+x and ctrl+v to do it. These are the same keys as in most Windows programs. The only program of importance where it does not work is the terminal emulator, where it doesn't work on Windows, either!
(There is also the middle-mouse "drag & drop" which was put into X to make it usable for terminals. Even the first version of X was designed to do clipboard operations, through "Cut Buffers". It appears the middle-mouse is really quite convienent, and also the fact that it was the only thing that worked in the terminal, led a lot of people, including programmers, to think it is the only mechanism available. This made some people (including me) to try to emulate ctrl+x/v by using the same buffer as the middle mouse, leading to the broken behavior about 5 years ago (it would have been better to have clipboard not work at all). However this has been corrected in all modern programs and toolkits)
This endless repetition of "copy and paste" indicates to me that a number of posts out there are working off a script. There certainly are problems with the Linux desktop, but plain "copy and paste" is not one of them, especially to a "new user" who would never even figure out how to run a program old enough to not have copy and paste (the complaint is similar to complaining that copy and paste does not work on Windows when you run Lotus 123). The endless repetition of this statement plus the apparent inability of the same posters to name any other problem leads me to believe that this is scripted by non-Linux users.
Hint for the scripted posters: you can update the script to say "copy and paste anything other than text". This is an area where Windows is certainly better, mostly because the morons working on X built a mechanism but refused to assign a few predefined numbers to mean "an image" or "rich text".
I would think most of the theoretical advantages with compiling packages yourself is not from different -O settings, but because #if statements inside the code may completely eliminate parts of it at compile time. For instance compiling out support for some back-compatability thing you don't have or use may speed up a program, and will certainly make it smaller.
This is all in theory, however. I am unsure if there is any reason for it. If machines get fast enough that people don't mind a compile as part of install then I see no reason not to distribute source-only. But the only definate advantage is the fact that the thing you download is far more likely to work, I am unsure if there would be performance advantages.
All very clever and it sounds like he knows what he is talking about.
However perhaps he should examing exactly how those new-fangled high-speed hardware boards work. Maybe examine how geometry is sent to them nowadays. Take a look at how those fragment/pixel shaders are stored and sent to the card. Take a look at how they get operations to happen on vertical retrace.
Hint: it looks a LOT like a stream. And this is designed by people who are desperate to get them to run as fast as possible.
You might also check why disk interfaces are going serial, and even the main bus may go serial someday.
"*bufferptr++ = x" is faster than any call, and can be easily parallelized. Also memcpy is much, much faster when you have a block of already-composed graphics. And if you studied it at all you would see that at least 90% of the operations a program do is "copy this precomposed graphic (which could be a letter or glyph) from memory to the device".
Just to be technical, pure "latency" is not the problem with X. You would be suprised at how easily you could use a machine where the display updated fast, but was delayed 1 second from anything you did. Shooting games might be difficult, but a lot of bad word form-filling software and the web work this way.
The round-trips are made bad by latency, but the real problem is that they require 2 whole latency steps for every call. Even a microsecond makes the display draw unbearably slow. Non-round-trip calls can be shoved down a pipe and thus hundreds of thousands can be sent in a second even if there is a second of "latency".
Even making a "DRI" interface, as is often suggested, will not help, as it still means a good number of machine instructions, pushing and popping, are done each call. Some misguided other posters seem to thing "marshalling" and "unmarshalling" are expensive, they are wrong. Ever wonder why things like "display lists" are used to make 3D hardware run fast?
Although using the rewritten Xlib interface will not be any faster, this will allow you to use the XCB interface as well, and perhaps gradually modify your program to 100% XCB.
I have not read the papers in quite awile, but the main reason XCB is faster is that it is a direct interface to the X wire protocol. If some Xlib call was something like "send message x", "wait for response x", in XCB these are two calls. The advantage is that you can do a lot of other stuff, such as sending other messages, between the send and the wait for response. In some cases this can turn the client-server model from a liability into a huge benifit.
For any X program, try Alt+Tab.
Perhaps you are using old framebuffer programs? Try Alt+F7 to switch back to X. But really I have not seen any of these lately. Any program wanting OpenGL is now better off using X.
You are seriously deluded about how much computing power is needed to change the pixels on the screen. A typical game now is changing the color of EVERY SINGLE PIXEL, up to 80 TIMES A SECOND, and is doing a much more complicated operation that just filling a shape with a constant.
Also it should be obvious that any of the symbolic graphics you are talking about can be drawn on a full-color display. The fact that many pixels have the same color does not mean that a colormap is required.
I have programmed with colormaps with cells reserved for "blink". I have also used sprites and overlay planes. Yes I can see why these were created, but I can also state with absolute conviction that I am glad they are gone.
The only reason Colormaps survived so long in X is because of the absurd design so that a colormapped machine could not pretend to be full-color. Windows (much to Unix's embarassment) at least made the true-color calls work and produce ugly dithering on colormapped displays. The result was that every program was rewritten quickly to not require colormaps because it was so vastly easier to use the true-color settings, and it soon became far more likely to find a full-color display used on Windows than on X. It was not until XFree86 with it's one-visual-only design that Linux displays caught up.
No. There seems to be this big delusion that somehow OpenSource has to rewrite virtually every commercial application.
Maybe commercial companies will port to Linux!! Oh no, you say, isn't that illegal by RMS's communist manifesto? Sorry to break your fantasy, but it is legal, only Microsoft wants you to believe otherwise.
Take a look at the special effects industry and you will see that there is lots of commercial, closed-source, for-profit software being written for Linux.
PS: What Linux really needs is to be pre-installed on machines in a store. However it appears that Microsoft is still disallowing dual-boot machines to be sold.
The wording here is really a bit too strange and not like a normal Microsoft attack. First of all anybody with any knowledge of history would put the "rock solid" joke on ME, not 95. And I never heard the "just for ME!" line before, in fact this is pronounce emm-e by every Microsoft hater. Though the background of XP is obvious teletubbies appearance, most Microsoft haters attack the candy-coloring bubbles which don't resemble Teletubbies scenery much at all. And "the radiator would dislodge?" How about "when you go over a bump it would stall" or otherwise do an obvious failure.
It should be obvious that Microsoft is setting this up. They want to attack OSS on security. Their plan is to put a hole or exploit into the code by compromising some system to infect the code. Possibly this has been caught three times now, but there may be a missed one already planted, so everybody check carefully! Notice that they plan to announce this "security" stuff apparently in sync with 2.6 being released.
The far easier way to plant a hole in Linux would be to pay off or threaten some developer to do it. However they cannot do this because of the obvious fact that this can be done to one of their employees as well. They have to do it by "hacking" and they need to print this paper to show that they are extremely well-protected against "hacking", while open-source is "vulnerable"
The several posts like this, which seem out of character (ie treating Microsoft as childish rather than a threatening if clumsy evil), I think are planted. They want to point out that this coming failure of open-source has nothing to do with the security of the software on your desktop, but everything to do with the fact that people can work on the code.