No, WindowMaker should be changed to use the standard icons. The current situation is as though you made your own shell that only ran it's own executable format and complained that people refused to recompile programs into your executable format. Getting the icon should be done by the same code in all programs, just like exec() is the same code in all programs.
IBM officially licensed the RCU patent to Linux for GPL use only. Is this an example of IBM giving away stuff so it cannot become entirely evil?
That's good! I was not aware they had actually done anything like this, just that people were trying to make them do so. Doing this is exactly what I was talking about, I was suspicious that IBM was not doing anything, just talking.
Although you seem to be trying to slant your argument into an anti-slashdot/pro-microsoft rant, the basic premise is quite true.
The company on top always fights standards, and the companies below it all claim "standards are good".
Even in recent history Microsoft has flip-flopped on this in instant messaging, because they were not number 1 in this, AOL was.
I fully agree that if IBM "wins" they will turn quite evil. And Microsoft will turn into the good guys so fast it will make everybody's head spin. Smarter people are trying to make sure that IBM truly gives away enough stuff so they cannot become entirely evil, such as officially saying that open source is allowed to use their patented technology. So far IBM has not been stupid enough to do that, but there is hope...
People thinking the GPL on Linux will save them are deluded. The design of the Intel 486 is documented quite well and can be duplicated (AMD did so) yet this did not mean that Microsoft could not run a closed-source Windows atop it. In the same way a fully open-source Linux bottom level would not prevent a closed-source upper layer from being written, much like OS/X's user interface code.
It's unclear why XP's defaults for the type face are so bad. However if you turn on ClearType for all sizes I think the appearance is much better on LCD's than the latest Freetype (and yes I turned on the RGB rendering there, too) and about equal on CRT's (my favorite output is actually a slightly dated FreeType compiled with the hinting disabled completely on a CRT, the text looks extremely smooth there, unfortunatley I will probably have to give up this version when I update the machine to a modern Linux).
Of course Kernigan was tense. It should be obvious that he stole the idea of using the '+' character to mean addition from Fortran! In fact there are literally thousands of ideas like that he stole from previous work!
It is obvious that the only way to create an original computer science work is to be raised by wolves, and then design and develop all the electronics and computational theory from scratch.
Probably a dozen times greater is how many times closed source vendors steal from other closed source. Companies stab each other in the back, ignore NDA's, actively engage in corporate espionage, and (perhaps by far the biggest) is programmers will steal from their previous employer, or steal from their wife or any relative or friend's employer, anything and everything they can.
Open source is in fact the only way to stop this. Only with open source do the cheaters fear getting detected and stop doing this. Unfortunately the FUD is going to convice all the idiots who make policy that exactly the opposite is true.
I agree that there does have to be a "manager", but mostly to make icons or panel type things work, and also to provide a place for other programs to find out what programs the user sees running.
To make it possible to move or resize dead applications, X could be changed so if there is too much delay after passing a mouse click to the program before it calls XGetEvent again, it instead passes it to the manager. So you could move dead windows, though they would not move until a second has passed. It would also help if programs can easily indicate "I'm not interested in this event" and the manager gets it in the same way, this would eliminate all need for "grabs" and allow a program access to all the shift keys, and allow windows to be dragged around by areas that are not doing anything.
I would think that "todays x.org" is going to resemble "tomorrows x.org" at least as much, and probably slightly more, than "todays XFree86" is going to resemble "tomorrows x.org".
GEM could run exactly four apps at the same time. This may well have been stupider than one app, though. GEM had a lot of other problems, my favorite was that they made double-click work by having the system wait long enough to report any click that it could tell whether it was a double click or not, thus by design there was a 1/2 second delay on any mouse actions!
1) The unified taskbar was available in some X implementations prior to 1991.
Putting the icons in a box or even in a strip along the edge existed, but I never saw an implementation that did not remove the icons when the window was "open". Leaving the icons there whether or not the window was open is the innovation I was talking about.
5) Absolute trash. CP/M actually contained this concept (although it was less obvious in those pre-graphics days) by requiring a specific extension for a file to be accessed by it's relevant program. VMS, Smalltalk, and numerous others also included this type of linkage in various forms.
Again I am unaware of any system doing this. I did not mean use of file extensions to identify the type of content. I did not mean using file extensions instead of meta data to identify the type of content. What I meant was using the type of content to identify the program to run. All systems prior to this required the user to select the program first and then open the file. Initially Apple's files contained a "creator id" which was a specific program, if you did not have that program you had to run another program and open the file conventionally. It seems to me it was Microsoft that first had the idea that the type->program mapping would be managed by the system.
Office-suite integration was taken from Claris (and I don't think they invented it either)
Or maybe Lotus, or actually any of dozens of companies that in the mid 1980's tried to make suites of programs that were sold seperatly but worked with each other.
This is a definate problem with X. As designed X could be a million times faster than Windows and you will still get glitches when you resize the windows. The solution, which nobody wants to admit, is to get rid of "window managers" and require the applications to draw the window borders themselves (notice that programs that do this like some MP3 players resize quite nicely). For a program that already has to draw buttons and text it probably takes about 1/10 as much code as it takes to talk to window managers, too. Unfortunatly whenever this is suggested people immediatly shout about that bogeyman: "inconsistency" and we are forced to remain with the same crap we have today.
Well I have to say Microsoft's documentation ain't too good, because I never found that (the command is called ShellExecute()). The technique I was doing was to exec "rundll32.exe url.dll,FileProtocolHandler" which was found after extensive searching on the Web for the solution.
Have to note however that the supposedly command-line-oriented Linux has absolutely NOTHING on even this. Why the hell isn't there an "open" program, or shells that open files when you type their name as the command? This would make writing file browsers 90% easier and immediatly get rid of the biggest incompatabilities between the desktops.
I don't see how this means that IE has to be integrated. You just said that you "open" word documents, yet Word is not "integrated". There is no reason that one of the types of documents (a web page in html) has to be different than others.
Now for some sanity: Microsoft DID invent some stuff, there are ideas in Windows 95 that I have not seen elsewhere before it, except in some of my own experiments (I did the exact same divider-less graphics for window borders in the "ViewKit" I wrote for NeXT, but I doubt Microsoft stole it from me).
1. The "taskbar" contained both opened and closed windows. All systems I have seen before then only showed closed windows, opened windows were either not represented or where in a different navigator.
2. The "taskbar" was the first indication that somebody has realized that text is important. They shrunk down the "icon" as small as possible (probably somebody at Microsoft tried to get rid of them, but was stopped by the "experts" who think easy-to-use == pictures). And they made the text in the taskbar icon prominent.
3. They got rid of the divider line between the window borders and the contents and made thw windows look a lot more like unified objects. (for some reason they have reverted to old-fashioned graphics today, unfortunatly the good graphic desiginers they had on Windows95 have apparently been replaced by Enlightenment geeks with no clean graphic sense whatsoever).
4. They supported drag-resize of windows, and hacked their system so it was fast enough to draw this on existing machines, rather than punting like far faster Unix machines were doing.
5. I belive Microsoft is responsible for a lot of the linking of "program to run" to the file itself. Every system I have ever seen before that required an explicit indicator as to the program to run. Apple's files contained this indication (the creator id) and is thus not exactly what Microsoft did. Now this could be done a whole lot better, such as using a program like Unix "file" to figure it out, and there is ZERO support at an os level (why isn't there a system call to exec a file?), but before Windows this idea did not exist.
Yes but all pages already have a "writable" bit. Why couldn't Intel make the processer reuse this bit as the "no execute" bit? That is what the original poster was asking.
Yes Windows supports this with a call to indicate that NX should be turned off on allocated pages. They added this because they wanted Windows to work on non-Intel processors at one time. Linux has a similar ability or it would be impossible to make exec work on such processors. The problem is that apparently programs don't bother calling this when they want memory for code because it is not necessary on Intel.
For compatabilty with such programs it will probably be necessary to have a mode where NX is off on all allocations, rather than on. This will not need any root permissions if it is per-process, if a malicious program can make this call it can already do lots of other nasty things.
This is not DRM and does nothing to stop downloaded code from running.
The NX bit is used to mark parts of memory of a running program. Certainly it will mark anything allocated from the heap, such as the memory used to store a piece of data downloaded from the net, and then written to the disk. However it does not have any magic "sticky" property that stays with the data. If the downloading program thinks that data is a program that should be run, rest assurred that it will have the capability of saving it on disk, turning on the execute file bit (on Linux), and exec'ing it, with no changes to the code from today.
Even today without the NX bit, I really doubt any program actually and deliberatly downloads blocks of data from the net and then jumps to it. What NX does is prevent that from happening due to a malicious program that somehow gets some data into memory including a jmp instruction to that data. This is possible today by overwriting the stack so the return address and malicious code is there.
The VAX had NX, this is not new technology. I'm assumming NX was not added for so long was that there was that there was no room to add a bit to do it to the page description. Though I don't understand why Intel didn't just make a mode where write-permission==NX so you cannot execute any page you can write to.
Actually what happened is that initially/usr was for home directories like you said. There was no/usr/bin.
The problem was that/usr was the "big" disk, while other things in / were on the "small" disk. This was before symbolic links, so if you wanted to store anything on the big disk it had to start with/usr. As soon as space was needed for more system files, they started appearing under/usr. Eventually/usr got so cluttered people started moving the home directories somewhere else. "Unix System Resources" is a joke backronym to try to hide this, the initial Unix design used "/" for this purpose.
I think you are confusing TopView, which was an IBM product, with early versions of Windows.
TopView was a disaster but it probably killed any of the competitors, including multidos and VisiOn. It was actually IBM pulling the Microsoft stunt of advance annoucement to kill your competitors.
Windows was always run in graphical mode, and was a good deal later than VisiOn. You are describing accurately the pre-3.0 tiled versions of Windows, however. I worked with those as well. The fonts were so bad that it did look like it was running in text mode, but it really was graphics.
Unfortunately this does not prove anything. You have not identified the problem with Linux.
THERE IS A STANDARD FOR CUT & PASTE!!!! If you actually read the other comments here and managed to sepearate the real information from the unbelievable pile of crap posted here (both by Linux lovers and Linux haters). You would know that there is a simple solution, and rules that if followed, would make BOTH cut & paste and the middle-mouse stuff work, in a much more convienent form than Windows (in reality the middle-mouse stuff is a much better drag & drop, because you can rearrange and open and close windows before dropping).
Unfortunately the problem is with older programs that don't follow the standards. The problem is not the lack of standards. What needs to be figured out is why Linux keeps running these older programs, why people don't fix them or care to fix them, and why there is such incredible ignorance that people are still unsure how to fix them.
(PS: To fix your damn application, make ctrl+x/v put the text into the CLIPBOARD, and paste from the CLIPBOARD. Don't worry that ctrl+v does not insert text from xterm, that is xterm's fault, not yours!! Xterm should be fixed so selection either lets you type ctrl+c or it automatically updates the clipboard on release).
Like a zillion other users here you are confused about where the problem is.
The problem is with programs that use the selection for ctrlx/v, instead of the clipboard. If you try ctrl+v into a WORKING program (such as any recent KDE or Gnome app) you will find the clipboard is unchanged by selecting the text. EMACS is broken, NOT "Linux".
If an application on Windows doing drag & drop caused the clipboard to change to the drag & drop text, or if doing paste always pasted the last thing you drag & dropped, this would be a similar (actually IDENTICAL) problem. However that does not prove "drag & drop sucks and should be removed" (which seems to be the prevailing opinion of noobs here). Instead it proves that there can be broken applicatcions.
Sorry I was unclear. What I meant was that "broken" programs would probably be better if ctrl+x/v did not do anything, verses their current behavior. A program where ctrl+x/v did the right thing is even better, and a program where both that and the middle-mouse do the right thing is best.
Not quite correct. Both buffers are identical and maintained by the X server. The only difference between them is their identifier. You can make up your own besides these two but nobody uses them.
Slashdot Mirror
No, WindowMaker should be changed to use the standard icons. The current situation is as though you made your own shell that only ran it's own executable format and complained that people refused to recompile programs into your executable format. Getting the icon should be done by the same code in all programs, just like exec() is the same code in all programs.
IBM officially licensed the RCU patent to Linux for GPL use only. Is this an example of IBM giving away stuff so it cannot become entirely evil?
That's good! I was not aware they had actually done anything like this, just that people were trying to make them do so. Doing this is exactly what I was talking about, I was suspicious that IBM was not doing anything, just talking.
Although you seem to be trying to slant your argument into an anti-slashdot/pro-microsoft rant, the basic premise is quite true.
The company on top always fights standards, and the companies below it all claim "standards are good".
Even in recent history Microsoft has flip-flopped on this in instant messaging, because they were not number 1 in this, AOL was.
I fully agree that if IBM "wins" they will turn quite evil. And Microsoft will turn into the good guys so fast it will make everybody's head spin. Smarter people are trying to make sure that IBM truly gives away enough stuff so they cannot become entirely evil, such as officially saying that open source is allowed to use their patented technology. So far IBM has not been stupid enough to do that, but there is hope...
People thinking the GPL on Linux will save them are deluded. The design of the Intel 486 is documented quite well and can be duplicated (AMD did so) yet this did not mean that Microsoft could not run a closed-source Windows atop it. In the same way a fully open-source Linux bottom level would not prevent a closed-source upper layer from being written, much like OS/X's user interface code.
It's unclear why XP's defaults for the type face are so bad. However if you turn on ClearType for all sizes I think the appearance is much better on LCD's than the latest Freetype (and yes I turned on the RGB rendering there, too) and about equal on CRT's (my favorite output is actually a slightly dated FreeType compiled with the hinting disabled completely on a CRT, the text looks extremely smooth there, unfortunatley I will probably have to give up this version when I update the machine to a modern Linux).
Such classes already exist at many universities!
Of course Kernigan was tense. It should be obvious that he stole the idea of using the '+' character to mean addition from Fortran! In fact there are literally thousands of ideas like that he stole from previous work!
It is obvious that the only way to create an original computer science work is to be raised by wolves, and then design and develop all the electronics and computational theory from scratch.
Closed source vendors steal from OSS all the time
Probably a dozen times greater is how many times closed source vendors steal from other closed source. Companies stab each other in the back, ignore NDA's, actively engage in corporate espionage, and (perhaps by far the biggest) is programmers will steal from their previous employer, or steal from their wife or any relative or friend's employer, anything and everything they can.
Open source is in fact the only way to stop this. Only with open source do the cheaters fear getting detected and stop doing this. Unfortunately the FUD is going to convice all the idiots who make policy that exactly the opposite is true.
I agree that there does have to be a "manager", but mostly to make icons or panel type things work, and also to provide a place for other programs to find out what programs the user sees running.
To make it possible to move or resize dead applications, X could be changed so if there is too much delay after passing a mouse click to the program before it calls XGetEvent again, it instead passes it to the manager. So you could move dead windows, though they would not move until a second has passed. It would also help if programs can easily indicate "I'm not interested in this event" and the manager gets it in the same way, this would eliminate all need for "grabs" and allow a program access to all the shift keys, and allow windows to be dragged around by areas that are not doing anything.
I would think that "todays x.org" is going to resemble "tomorrows x.org" at least as much, and probably slightly more, than "todays XFree86" is going to resemble "tomorrows x.org".
That's for Linksys, not Netgear!
GEM could run exactly four apps at the same time. This may well have been stupider than one app, though. GEM had a lot of other problems, my favorite was that they made double-click work by having the system wait long enough to report any click that it could tell whether it was a double click or not, thus by design there was a 1/2 second delay on any mouse actions!
Putting the icons in a box or even in a strip along the edge existed, but I never saw an implementation that did not remove the icons when the window was "open". Leaving the icons there whether or not the window was open is the innovation I was talking about.
5) Absolute trash. CP/M actually contained this concept (although it was less obvious in those pre-graphics days) by requiring a specific extension for a file to be accessed by it's relevant program. VMS, Smalltalk, and numerous others also included this type of linkage in various forms.
Again I am unaware of any system doing this. I did not mean use of file extensions to identify the type of content. I did not mean using file extensions instead of meta data to identify the type of content. What I meant was using the type of content to identify the program to run. All systems prior to this required the user to select the program first and then open the file. Initially Apple's files contained a "creator id" which was a specific program, if you did not have that program you had to run another program and open the file conventionally. It seems to me it was Microsoft that first had the idea that the type->program mapping would be managed by the system.
Office-suite integration was taken from Claris (and I don't think they invented it either)
Or maybe Lotus, or actually any of dozens of companies that in the mid 1980's tried to make suites of programs that were sold seperatly but worked with each other.
This is a definate problem with X. As designed X could be a million times faster than Windows and you will still get glitches when you resize the windows. The solution, which nobody wants to admit, is to get rid of "window managers" and require the applications to draw the window borders themselves (notice that programs that do this like some MP3 players resize quite nicely). For a program that already has to draw buttons and text it probably takes about 1/10 as much code as it takes to talk to window managers, too. Unfortunatly whenever this is suggested people immediatly shout about that bogeyman: "inconsistency" and we are forced to remain with the same crap we have today.
Well I have to say Microsoft's documentation ain't too good, because I never found that (the command is called ShellExecute()). The technique I was doing was to exec "rundll32.exe url.dll,FileProtocolHandler" which was found after extensive searching on the Web for the solution.
Have to note however that the supposedly command-line-oriented Linux has absolutely NOTHING on even this. Why the hell isn't there an "open" program, or shells that open files when you type their name as the command? This would make writing file browsers 90% easier and immediatly get rid of the biggest incompatabilities between the desktops.
I don't see how this means that IE has to be integrated. You just said that you "open" word documents, yet Word is not "integrated". There is no reason that one of the types of documents (a web page in html) has to be different than others.
"Popularized" is not "invented"
Now for some sanity: Microsoft DID invent some stuff, there are ideas in Windows 95 that I have not seen elsewhere before it, except in some of my own experiments (I did the exact same divider-less graphics for window borders in the "ViewKit" I wrote for NeXT, but I doubt Microsoft stole it from me).
1. The "taskbar" contained both opened and closed windows. All systems I have seen before then only showed closed windows, opened windows were either not represented or where in a different navigator.
2. The "taskbar" was the first indication that somebody has realized that text is important. They shrunk down the "icon" as small as possible (probably somebody at Microsoft tried to get rid of them, but was stopped by the "experts" who think easy-to-use == pictures). And they made the text in the taskbar icon prominent.
3. They got rid of the divider line between the window borders and the contents and made thw windows look a lot more like unified objects. (for some reason they have reverted to old-fashioned graphics today, unfortunatly the good graphic desiginers they had on Windows95 have apparently been replaced by Enlightenment geeks with no clean graphic sense whatsoever).
4. They supported drag-resize of windows, and hacked their system so it was fast enough to draw this on existing machines, rather than punting like far faster Unix machines were doing.
5. I belive Microsoft is responsible for a lot of the linking of "program to run" to the file itself. Every system I have ever seen before that required an explicit indicator as to the program to run. Apple's files contained this indication (the creator id) and is thus not exactly what Microsoft did. Now this could be done a whole lot better, such as using a program like Unix "file" to figure it out, and there is ZERO support at an os level (why isn't there a system call to exec a file?), but before Windows this idea did not exist.
Yes but all pages already have a "writable" bit. Why couldn't Intel make the processer reuse this bit as the "no execute" bit? That is what the original poster was asking.
More confusion with DRM.
Yes Windows supports this with a call to indicate that NX should be turned off on allocated pages. They added this because they wanted Windows to work on non-Intel processors at one time. Linux has a similar ability or it would be impossible to make exec work on such processors. The problem is that apparently programs don't bother calling this when they want memory for code because it is not necessary on Intel.
For compatabilty with such programs it will probably be necessary to have a mode where NX is off on all allocations, rather than on. This will not need any root permissions if it is per-process, if a malicious program can make this call it can already do lots of other nasty things.
This is not DRM and does nothing to stop downloaded code from running.
The NX bit is used to mark parts of memory of a running program. Certainly it will mark anything allocated from the heap, such as the memory used to store a piece of data downloaded from the net, and then written to the disk. However it does not have any magic "sticky" property that stays with the data. If the downloading program thinks that data is a program that should be run, rest assurred that it will have the capability of saving it on disk, turning on the execute file bit (on Linux), and exec'ing it, with no changes to the code from today.
Even today without the NX bit, I really doubt any program actually and deliberatly downloads blocks of data from the net and then jumps to it. What NX does is prevent that from happening due to a malicious program that somehow gets some data into memory including a jmp instruction to that data. This is possible today by overwriting the stack so the return address and malicious code is there.
The VAX had NX, this is not new technology. I'm assumming NX was not added for so long was that there was that there was no room to add a bit to do it to the page description. Though I don't understand why Intel didn't just make a mode where write-permission==NX so you cannot execute any page you can write to.
Actually what happened is that initially /usr was for home directories like you said. There was no /usr/bin.
/usr was the "big" disk, while other things in / were on the "small" disk. This was before symbolic links, so if you wanted to store anything on the big disk it had to start with /usr. As soon as space was needed for more system files, they started appearing under /usr. Eventually /usr got so cluttered people started moving the home directories somewhere else. "Unix System Resources" is a joke backronym to try to hide this, the initial Unix design used "/" for this purpose.
The problem was that
I think you are confusing TopView, which was an IBM product, with early versions of Windows.
TopView was a disaster but it probably killed any of the competitors, including multidos and VisiOn. It was actually IBM pulling the Microsoft stunt of advance annoucement to kill your competitors.
Windows was always run in graphical mode, and was a good deal later than VisiOn. You are describing accurately the pre-3.0 tiled versions of Windows, however. I worked with those as well. The fonts were so bad that it did look like it was running in text mode, but it really was graphics.
That's only a problem if those open-source drivers actually work with the competitor's hardware.
Unfortunately this does not prove anything. You have not identified the problem with Linux.
THERE IS A STANDARD FOR CUT & PASTE!!!! If you actually read the other comments here and managed to sepearate the real information from the unbelievable pile of crap posted here (both by Linux lovers and Linux haters). You would know that there is a simple solution, and rules that if followed, would make BOTH cut & paste and the middle-mouse stuff work, in a much more convienent form than Windows (in reality the middle-mouse stuff is a much better drag & drop, because you can rearrange and open and close windows before dropping).
Unfortunately the problem is with older programs that don't follow the standards. The problem is not the lack of standards. What needs to be figured out is why Linux keeps running these older programs, why people don't fix them or care to fix them, and why there is such incredible ignorance that people are still unsure how to fix them.
(PS: To fix your damn application, make ctrl+x/v put the text into the CLIPBOARD, and paste from the CLIPBOARD. Don't worry that ctrl+v does not insert text from xterm, that is xterm's fault, not yours!! Xterm should be fixed so selection either lets you type ctrl+c or it automatically updates the clipboard on release).
Like a zillion other users here you are confused about where the problem is.
The problem is with programs that use the selection for ctrlx/v, instead of the clipboard. If you try ctrl+v into a WORKING program (such as any recent KDE or Gnome app) you will find the clipboard is unchanged by selecting the text. EMACS is broken, NOT "Linux".
If an application on Windows doing drag & drop caused the clipboard to change to the drag & drop text, or if doing paste always pasted the last thing you drag & dropped, this would be a similar (actually IDENTICAL) problem. However that does not prove "drag & drop sucks and should be removed" (which seems to be the prevailing opinion of noobs here). Instead it proves that there can be broken applicatcions.
Sorry I was unclear. What I meant was that "broken" programs would probably be better if ctrl+x/v did not do anything, verses their current behavior. A program where ctrl+x/v did the right thing is even better, and a program where both that and the middle-mouse do the right thing is best.
Not quite correct. Both buffers are identical and maintained by the X server. The only difference between them is their identifier. You can make up your own besides these two but nobody uses them.