One reason that Linux looks like Windows is that Windows actually copied a lot of ideas from existing X implementations, as well as from the Mac.
The menubar style of Windows apps is from X. The Mac menubar cannot be done in a point-to-type environment, also it was more of an X design to not have a particular app be "active" but to have them all be equal. Turning open windows into an icon with 1:1 mapping between each icon and each window is from X (this is how Windows worked before '95). Keyboard navigation was exactly copied from the CDE/Motif environment, including the Alt+Tab (MicroSoft improved this by making Alt+Tab go to iconized windows, CDE required the mouse to open an iconized window), and the meaning of ctrl and shift on navigating lists of items.
In fact I see a lot more of X in MicroSoft's interface than Macintosh. The main thing taken from Mac is desktop icons (ie icons that do not correspond to windows). Also the keyboard bindings could claim to be copied from Mac, though at the time almost all X applications were copying the Mac bindings as well (one big difference is that the X applications, and most MSDOS ones, used the "Alt" key, MicroSoft's insistance on using "Ctrl" resulted in a huge mess and is mostly responsible for the claims that X appliations are inconsistent).
Don't worry, both KDE and Gnome are busy copying the click-raises-the-window "feature" so you can be just as annoyed with Linux as with Windows! It is very frustrating to see this, I like Linux because it is different and innovative, not because it is "not MicroSoft".
Seriouisly, you can fix NT by editing a registry setting so it is point-to-type, which will work as long as you can navigate your cursor without clicking. There is NO way to prevent a click from raising the window, even if you write the program that owns the window!
The KDE window manager (not Gnome yet) is getting really bad at assumming this. It is almost impossible to turn this off and still have a functioning window manager. This is really really sad.
Although this is the obvious way that a trojan can get root on Linux, this sort of exploit is also possible on Windows and does not seem to be used much. It is even more trivial to make a piece of NT "shareware" that is in fact a dangerous virus and that gets power because it requires the administrator to "install" (and on Windows anybody can "install").
The fact that I have never heard of such a trojan (or at least not a damaging one) is an indication that this does not work. I think this is because such a trojan would be detected and disabled (or at least warned about) long before it did much damage.
Re:Unix Worms - what have they done lately?
on
Linux Virus Alert
·
· Score: 2
The "fascist" remark is some comment from RMS about the "wheel" group, which if I understand, is the only group allowed to su to root. According to RMS this is somehow "fascist" and restricts the rights of users. I don't quite understand the argument in either direction (I can't see how this helps security, nor do I see how it can harm users).
But anyway, the feature is not in Redhat, the documentation you cite is an explanation of why RMS does not like the feature and why it is not supported by Gnu tools. So in fact the documentation claims that Redhat lacks the fascist feature.
My guess is that this is WINE on Linux, but that X has been ripped out and replaced with another windowing system whose only purpose is to provide whatever is necessary for WINE. I would expect this could be done and still reuse the lower levels of XFree86, or they may have written the video system themselves. The reason for this is that they don't make any claim to run Linux graphics applications.
This is exactly the sort of crap that MicroSoft does and why programmers hate it.
If you say that "MyDocuments" is equivalent to the Unix "home" directory, notice that on Unix the method to get this information is to call getenv("HOME"), while apparently on MicroSoft it is the new getMyDocumentsDirectory() call. Notice that the Unix solution reuses a current interface. If home directories did not exist before and they were added to Unix, most systems (like perl, etc) would already have the getenv() call and could immediately take advantage of it. The MicroSoft solution requires perl to be recompiled to call this.
I can find no clearer explanation as to why software engineers hate MicroSoft.
And they definately do this to break things. They have getenv() and a zillion other things (registry, for instance) to look up a string such as the MyDocuments directory name, but they insist on adding a new call. The fact is the engineers at MicroSoft are not idiots and it should be obvious that there are better ways to do this than adding new calls, but they are also blinded by absolute hatred for anything outside MicroSoft that they will gladly throw good engineering out in order to force people to stick to their platform.
Static displays of arbitrary shape and complexity can be created using off-the-shelf components. These are very popular for Christmas decorations on the exteriors of houses.
They were not allowed to sell *DUAL BOOT* machines, which would have been hundreds of times more popular.
MicroSoft either does not care or cannot legally do anything about Linux-only machines. As far as I know they never have been able to prevent a manufacturer from making them, despite claims to the contrary here. But they can prevent dual-boot machines and this has completely killed any chance of anybody buying Linux (or, more interestingly, any possibility of an alternative commercial operating system such as BeOS or something designed to play games).
I agree, they don't realize how badly this will backfire. Right now if somebody wants to play an MP3 on their MP3 player, or even to steal a copy and give it to their friend, they go and purchase the disk, put it in their computer, and make the MP3.
Now suddenly attempts to do this don't work. So what do they do? They go to the net and search for the MP3 and download it. Then they play it and give it to their friend like before. But gee, now that they have to do all this searching on the internet, why bother buying the disk?
They can prosecute MP3 traders right now under existing laws, because they are violating copyright. The fact that they are not doing this prosecution is proof that the entire "pirate" reasoning behind the DMCA and SSSCA, etc is a lie.
Tooltips may serve a purpose by providing a lengthy explanation that cannot fit in the button, or by being used as a display of information about the state of the program (ie exactly what this button will do now).
However I do agree that the buttons should have short bits of text on them. The current designs with icons is absolutely insane. And yes it is managers who say "pictures == user-friendly" and force the programmers to do this crap.
He's not talking about the difference between CLI/GUI. He's talking about the difference between putting a little line drawing of a 3.5" floppy disk on a button and putting the word "Save" on that button.
Geez, so many people think that "text" means "CLI"! It doesn't. Open your eyes.
Are you really sure it would not be easier if that image that is a line drawing of a 3.5" floppy disk (an object you probably don't even use!) instead was the word "Save"?
Yea, buttons to click on are great. Putting pictures on them is not so great.
It would also help if they got it through their thick skulls that there is no difference between a "toolbar" and the "menubar" and put them together. A "toolbar button" is simply a top-level item on the menu bar that HAS NO SUBMENU.
It seems to me he is comparing "placing things on the desktop" with "placing things inside a storage window" (ie a finder). He proposes that that the storage window is bad (though he seems to think that placing "folders" on the desktop is ok, though that looks exactly to me like a storage window with a desktop icon to open it). Because the desktop can fill up he then proposes that many desktops (pretty unrelated to Linux virtual desktops, by the way) be used to give more space.
I think his alternative will fail the moment the user needs to move an item from one desktop to another.
The only alternative I think to current usage is to make the desktop only be a surface for windows to lie on. All files go into a "storage application", which is probably launched the same way as any other program. For most users this storage appliation would be exactly like the desktop except it would be in a window, which would allow it to be resized, raised atop other windows, etc. You could still drag & drop on it.
Sad but true, it appears that saving and loading MSWord format is the only interoperability these things have!
On a serious note, this may be an undesirable but necessary result. It is hundreds of times more important that these programs read/write MSWord than that they read/write some "standard" that MicroSoft is going to ignore. And they get interoperabilty for free as a side effect, reducing the need for this standard format to nearly zero.
A standard format's real use would be to make it easy to write small stand-alone programs that generate or manipulate text. That would be extremely nice but I don't think it is going to happen while MicroSoft controls everything.
Middle-mouse cut & paste works just fine between these two and every other X program I have ever seen.
I think you mean the command-key based cut & paste, which admittedly does not work.
The problem here is that most programs originally used the middle-mouse buffer for this. This totally confuses Windows users because selection of text to replace trashes the buffer, so there was a decision (used by Motif & GTK, and newest versions of Qt) to use a different buffer for this. Unfortunately older programs will still use the older buffer (or don't have command-key cut&paste at all) and thus do not interoperate.
You probably want to use a directory to make these files. The "data" is one file in the directory, each "resource" is another file in that directory. Then modify the gui and command-line tools so that directories work like single files unless you use the right tools to look into them.
I think you meant that magic numbers and #! replaces the metadata, and I agree with that. It would help a lot if Windows and KDE and Gnome would go back to using magic numbers rather than registries of file name extensions. The main reason they don't is that on current file systems it is way faster to read a file name than to read the first few bytes of the file.
Bzzt. Wrong. There is no central database that Windows programs read to figure out their key bindings. In fact the bindings are picked by the application writer the same way Linux ones are.
All modern KDE and Gnome Linux programs copy the same keybindings that Windows programs use, and are just as consistent as Windows programs.
There are *old* Linux programs, such as editors with older command sets. There are also programmers like me who disagree with some ctrl key editing combinations (everybody agrees on cut/copy/paste/undo, but I cannot function unless ^D deletes forward, ^A to start of line, ^E goes to end of line, and ^K deletes to end of line, these often show up in Windows programs for the same reasons). There are also bugs and design mistakes (the whole cut & paste verses the middle-mouse copy & paste, which is really drag & drop in disguise but confused with cut & paste by endless numbers of X programs).
But there is nothing in the Windows system that isn't in Linux forcing the keybindings. And there is no reason for the same forces that make Windows programs "consistent" to not work for Linux.
This cannot work, because it requires the defintion of a "set" of operations that everybody agrees on.
Imagine we have this giant set of actions (like cut, paste, copy...) and the system turns keystrokes into these. Then I invent a new program that has this really good action called "frob". If this system is badly designed, it is impossible for me to make this program work without registering "frob" with the X consortium and every single machine being reprogrammed to produce "frob".
Now that would be a stupid design, so lets assumme I can just put "alt+F in my program does frob" and it works on all normal setups. But what if somebody has said "alt+F is Copy". Either Copy does not work in my program, or it is impossible to get "frob". You lose in either case.
The only thing that will work is standardization of what the keystrokes themselves do.
Under X the window manager (and other programs, but few, if any, actually do this) can "grab" a key or mouse combination. A key combination is a specific set of shift keys held down plus a single key on the keyboard. For instance "Alt+A" can be grabbed, but this will leave A and Alt+Shift+A and all other combinations ungrabbed. A mouse button can also be grabbed in the same way.
I think it is possible to grab a "set" of mouse buttons like left+right+Alt, but I know of no programs doing this. There are also numerous options for limiting the cursor to certain windows and forcing the cursor icon to a certain value, this functionality was originally designed for screen-capture programs, and all this stuff is quite irrelevant to the main use for window managers.
When something is "grabbed", when the user types that combination, it gets sent to the window manager, and the program that would have normally gotten it *does not get it*. There is absolutely no way for that program to know that it missed the keystrokes, and in fact it is impossible for a program to even find out what keystrokes are being "grabbed".
A typical Linux window manager will "grab" Alt+Tab to switch windows and Alt+left-mouse to move the window around. This means no program can use Alt+left-mouse for anything, and also means the user must hold down Alt even though there is no other reason to click on an area than to move a window.
A better design would be to have X programs indicate if they "understand" each keystroke. Keystrokes that are not understood would be passed to the parent window (ie the window manager window frame, or the desktop). This would allow window managers and other programs to "grab" as many keys as they want, with no setup (the can just look at the keys as they come in) and the applications get first dibs on all keystrokes.
That would make sense but Sony's actions seem to prove this false:
Chip 1 allows people to play copied games. You can make the excuse that this is for "backups" but we all know this is for piracy. Sony does NOTHING.
Chip 2 does what Chip 1 does and also allows imported disks to be played. Sony SUES.
Now what is the difference between chip 1 and chip 2 that made Sony attack? Hmm, maybe the have different priorities than you think...
Of COURSE these chips are used for piracy. Only idiots (and yea a couple post on SlashDot) would think otherwise. The companies are continually feeding us the lie that they are worried about piracy, but their actions are pretty clear about where they really want control.
Think about this in the future, when even the pirated copy of your movie will not let you fast-forward through the commercials and requires you to pay a monthy bill to watch it.
Slashdot Mirror
The menubar style of Windows apps is from X. The Mac menubar cannot be done in a point-to-type environment, also it was more of an X design to not have a particular app be "active" but to have them all be equal. Turning open windows into an icon with 1:1 mapping between each icon and each window is from X (this is how Windows worked before '95). Keyboard navigation was exactly copied from the CDE/Motif environment, including the Alt+Tab (MicroSoft improved this by making Alt+Tab go to iconized windows, CDE required the mouse to open an iconized window), and the meaning of ctrl and shift on navigating lists of items.
In fact I see a lot more of X in MicroSoft's interface than Macintosh. The main thing taken from Mac is desktop icons (ie icons that do not correspond to windows). Also the keyboard bindings could claim to be copied from Mac, though at the time almost all X applications were copying the Mac bindings as well (one big difference is that the X applications, and most MSDOS ones, used the "Alt" key, MicroSoft's insistance on using "Ctrl" resulted in a huge mess and is mostly responsible for the claims that X appliations are inconsistent).
Seriouisly, you can fix NT by editing a registry setting so it is point-to-type, which will work as long as you can navigate your cursor without clicking. There is NO way to prevent a click from raising the window, even if you write the program that owns the window!
The KDE window manager (not Gnome yet) is getting really bad at assumming this. It is almost impossible to turn this off and still have a functioning window manager. This is really really sad.
The fact that I have never heard of such a trojan (or at least not a damaging one) is an indication that this does not work. I think this is because such a trojan would be detected and disabled (or at least warned about) long before it did much damage.
But anyway, the feature is not in Redhat, the documentation you cite is an explanation of why RMS does not like the feature and why it is not supported by Gnu tools. So in fact the documentation claims that Redhat lacks the fascist feature.
My guess is that this is WINE on Linux, but that X has been ripped out and replaced with another windowing system whose only purpose is to provide whatever is necessary for WINE. I would expect this could be done and still reuse the lower levels of XFree86, or they may have written the video system themselves. The reason for this is that they don't make any claim to run Linux graphics applications.
If you say that "MyDocuments" is equivalent to the Unix "home" directory, notice that on Unix the method to get this information is to call getenv("HOME"), while apparently on MicroSoft it is the new getMyDocumentsDirectory() call. Notice that the Unix solution reuses a current interface. If home directories did not exist before and they were added to Unix, most systems (like perl, etc) would already have the getenv() call and could immediately take advantage of it. The MicroSoft solution requires perl to be recompiled to call this.
I can find no clearer explanation as to why software engineers hate MicroSoft.
And they definately do this to break things. They have getenv() and a zillion other things (registry, for instance) to look up a string such as the MyDocuments directory name, but they insist on adding a new call. The fact is the engineers at MicroSoft are not idiots and it should be obvious that there are better ways to do this than adding new calls, but they are also blinded by absolute hatred for anything outside MicroSoft that they will gladly throw good engineering out in order to force people to stick to their platform.
Static displays of arbitrary shape and complexity can be created using off-the-shelf components. These are very popular for Christmas decorations on the exteriors of houses.
MicroSoft either does not care or cannot legally do anything about Linux-only machines. As far as I know they never have been able to prevent a manufacturer from making them, despite claims to the contrary here. But they can prevent dual-boot machines and this has completely killed any chance of anybody buying Linux (or, more interestingly, any possibility of an alternative commercial operating system such as BeOS or something designed to play games).
Now suddenly attempts to do this don't work. So what do they do? They go to the net and search for the MP3 and download it. Then they play it and give it to their friend like before. But gee, now that they have to do all this searching on the internet, why bother buying the disk?
They can prosecute MP3 traders right now under existing laws, because they are violating copyright. The fact that they are not doing this prosecution is proof that the entire "pirate" reasoning behind the DMCA and SSSCA, etc is a lie.
Not quite, that won't hide the older names. Now they see "Configuration" and "etc" which is even more confusing.
However I do agree that the buttons should have short bits of text on them. The current designs with icons is absolutely insane. And yes it is managers who say "pictures == user-friendly" and force the programmers to do this crap.
Geez, so many people think that "text" means "CLI"! It doesn't. Open your eyes.
Yea, buttons to click on are great. Putting pictures on them is not so great.
It would also help if they got it through their thick skulls that there is no difference between a "toolbar" and the "menubar" and put them together. A "toolbar button" is simply a top-level item on the menu bar that HAS NO SUBMENU.
I think his alternative will fail the moment the user needs to move an item from one desktop to another.
The only alternative I think to current usage is to make the desktop only be a surface for windows to lie on. All files go into a "storage application", which is probably launched the same way as any other program. For most users this storage appliation would be exactly like the desktop except it would be in a window, which would allow it to be resized, raised atop other windows, etc. You could still drag & drop on it.
I think for KOffice it is going to be way way lower, like 1%.
On a serious note, this may be an undesirable but necessary result. It is hundreds of times more important that these programs read/write MSWord than that they read/write some "standard" that MicroSoft is going to ignore. And they get interoperabilty for free as a side effect, reducing the need for this standard format to nearly zero.
A standard format's real use would be to make it easy to write small stand-alone programs that generate or manipulate text. That would be extremely nice but I don't think it is going to happen while MicroSoft controls everything.
Because if they don't list the operating systems supported most people would assumme Windows only!
However I would question the claim that other systems did have it at that time, can anybody confirm?
I think you mean the command-key based cut & paste, which admittedly does not work.
The problem here is that most programs originally used the middle-mouse buffer for this. This totally confuses Windows users because selection of text to replace trashes the buffer, so there was a decision (used by Motif & GTK, and newest versions of Qt) to use a different buffer for this. Unfortunately older programs will still use the older buffer (or don't have command-key cut&paste at all) and thus do not interoperate.
I think you meant that magic numbers and #! replaces the metadata, and I agree with that. It would help a lot if Windows and KDE and Gnome would go back to using magic numbers rather than registries of file name extensions. The main reason they don't is that on current file systems it is way faster to read a file name than to read the first few bytes of the file.
All modern KDE and Gnome Linux programs copy the same keybindings that Windows programs use, and are just as consistent as Windows programs.
There are *old* Linux programs, such as editors with older command sets. There are also programmers like me who disagree with some ctrl key editing combinations (everybody agrees on cut/copy/paste/undo, but I cannot function unless ^D deletes forward, ^A to start of line, ^E goes to end of line, and ^K deletes to end of line, these often show up in Windows programs for the same reasons). There are also bugs and design mistakes (the whole cut & paste verses the middle-mouse copy & paste, which is really drag & drop in disguise but confused with cut & paste by endless numbers of X programs).
But there is nothing in the Windows system that isn't in Linux forcing the keybindings. And there is no reason for the same forces that make Windows programs "consistent" to not work for Linux.
Imagine we have this giant set of actions (like cut, paste, copy...) and the system turns keystrokes into these. Then I invent a new program that has this really good action called "frob". If this system is badly designed, it is impossible for me to make this program work without registering "frob" with the X consortium and every single machine being reprogrammed to produce "frob".
Now that would be a stupid design, so lets assumme I can just put "alt+F in my program does frob" and it works on all normal setups. But what if somebody has said "alt+F is Copy". Either Copy does not work in my program, or it is impossible to get "frob". You lose in either case.
The only thing that will work is standardization of what the keystrokes themselves do.
PS: I am NOT defending this lame-o design!
Under X the window manager (and other programs, but few, if any, actually do this) can "grab" a key or mouse combination. A key combination is a specific set of shift keys held down plus a single key on the keyboard. For instance "Alt+A" can be grabbed, but this will leave A and Alt+Shift+A and all other combinations ungrabbed. A mouse button can also be grabbed in the same way.
I think it is possible to grab a "set" of mouse buttons like left+right+Alt, but I know of no programs doing this. There are also numerous options for limiting the cursor to certain windows and forcing the cursor icon to a certain value, this functionality was originally designed for screen-capture programs, and all this stuff is quite irrelevant to the main use for window managers.
When something is "grabbed", when the user types that combination, it gets sent to the window manager, and the program that would have normally gotten it *does not get it*. There is absolutely no way for that program to know that it missed the keystrokes, and in fact it is impossible for a program to even find out what keystrokes are being "grabbed".
A typical Linux window manager will "grab" Alt+Tab to switch windows and Alt+left-mouse to move the window around. This means no program can use Alt+left-mouse for anything, and also means the user must hold down Alt even though there is no other reason to click on an area than to move a window.
A better design would be to have X programs indicate if they "understand" each keystroke. Keystrokes that are not understood would be passed to the parent window (ie the window manager window frame, or the desktop). This would allow window managers and other programs to "grab" as many keys as they want, with no setup (the can just look at the keys as they come in) and the applications get first dibs on all keystrokes.
Chip 1 allows people to play copied games. You can make the excuse that this is for "backups" but we all know this is for piracy. Sony does NOTHING.
Chip 2 does what Chip 1 does and also allows imported disks to be played. Sony SUES.
Now what is the difference between chip 1 and chip 2 that made Sony attack? Hmm, maybe the have different priorities than you think...
Of COURSE these chips are used for piracy. Only idiots (and yea a couple post on SlashDot) would think otherwise. The companies are continually feeding us the lie that they are worried about piracy, but their actions are pretty clear about where they really want control.
Think about this in the future, when even the pirated copy of your movie will not let you fast-forward through the commercials and requires you to pay a monthy bill to watch it.