Note that this apperent "newbie" knows there are things called "libraries" and that they reside on the disk, and perhaps knows that they are needed to run programs. He also has no problem with the fact that clicking around in the file chooser you can visit a folder called "windows/system32" and see the "libraries" there. He then goes on to praise this all as user-friendly and the way it should be.
On Linux, he either knew (or guessed correctly) that there are also things called "libraries". However they are in a directory called "/usr/local/lib". And by clicking around in the file chooser, you can see that. Yet somehow this is considered a horrible user-hostile thing on Linux!
It should be pretty obvious that the ideas are absolutely identical, except the names are changed. The problem is that people are absolutly used to Windows and have learned quite a lot of detail about how it works, perhaps a suprising amount, that even they will claim they don't know. This is exactly like your inability to use Windows until a copy of tcsh is installed, even if you only use it to run programs that you could type into cmd.exe or the "run box". Familiarity completely masks the fact that the level of complexity is identical, instead the familiar one feels as easy as breathing, while the unknown one is shown in it's exact complexity.
The solution may be to live with emulating Windows more. The problem here is that Window file layout is really bad. Still, where Linux is obviously better (having a home directory with your personal settings inside it) it seems even newbies pick it up. But putting everything else in capitalized-named directories in the root may be a huge barrier fix. Then again I may be underestimating, perhaps everything has to be put in directories named "Programs and Documents" and "windows32" because those are the "intuitive" and "obvious" names.
The obvious problem is that Unix users are used to the current mess, and make excuses for the multiple locations that are long obsolete (such as read-only file systems). Besides it can be emulated with symlinks. The less obvious problem is that some Linux developers actually believe all those Windows users who say they can use a computer without "knowing anything", so they feel there is no need to change the names of these directories since that is a system detail that a "newbie" obviously does not know. But, as the above poster shows, the "newbie" does in fact know this in elaborate detail, even if they don't know "why" it works that way, they know elaborate details about Windows and cannot stand it being too different.
The article would be more accurate if it said "This was caused by something as seemingly harmless as a missing closing parenthesis, plus the unfortunate loss of an open parenthesis that caused this mistake to not be detected by the compiler"
I just checked, and stupid gcc does not produce any warning whatsoever. I tried it as C++, I tried -Wall and -W, and still nothing. Not a good showing there.
I think the proper warning is that the test is constant. "geteuid != 0" is always true.
I remember seeing in 1986 or so, a 300-dpi crt monitor. It was monochrome, and probably only 1-bit/pixel, and was page-oriented (taller than wide). However it seemed pretty impressive, as it was exactly the same resolution as the laser printers at that time, and using monochrome 1-bit/pixel was still pretty common at that time. This was at a trade show (siggraph?). Certainly it would seem very useful to somebody writing documents, or reading them.
Anyway it's pretty obvious that idea was a dead end. I'm sure there were technical problems in that software had to be rewritten to use it. I'm sure the lack of color was a problem (and could not be solved, as crt color masks can't be made that resolution). But still it sounds like it would be useful, but never saw it in the real world.
Some other people made comments that the problem is that programs specify font sizes in pixels instead of points or something. This is misleading. Both X and Windows actually did specify fonts in "points", the problem is that *everything else*, such as lines and boxes, were specified in pixels. Trying to draw in two different coordinate systems with an almost arbitrary relationship is impossible, so programs would break badly when you went to a different system with a different DPI. Windows initially fixed this by allowing font sizes to be negative to indicate size in pixels, and then finally (win95 or 8?) just fixed the scale between "points" and "pixels" to be 4/3, ignoring the DPI resolution. X has still not figured this out and you still get screwed up output if you plug in the wrong monitor, but the newest api (Cairo) does get rid of specifying fonts in anything other than the same units as drawing, *finally*!!!
Replacing the DLL's is a BAD idea, and I think all newer Windows installs don't do this. You can put the needed copy of the DLL in your application directory itself, just as the original poster suggested. Don't put anything in there that seems to be provided by default (easily tested by trying to run your software on a non-development machine) Though occasionally I have had an end user need some mysterious xyzzy32.dll and had to direct them to the net to get it (all I can guess is that they threw their copy away or some virus did it), the base functions seem to be consistently provided on all versions of Windows, and the bundled.dll's are typically very application specific and not provided by Microsoft (so there won't be any automatic patching of them anyway).
The same solution can work for Linux. There is a switch to the linker (-Wl,--rpath,'${ORIGIN}' passed to g++) that makes it look in the executable directory for libraries. (in addition, readlink("/proc/self/exe") can get the information that should be in argv[0] so you can locate files other than libraries). To figure out what libraries you need to include, just like Windows, try running on a non-development machine, perhaps a different distribution.
The problem with Linux is that there is a little less stuff in the base, such as a version of Qt or gtk that is likely to link with your program. And these things are truly huge, it would be like including an entire copy of Windows with a windows app. My solution is to use fltk, statically linked, but that may not fly with all developers. If you do include large libraries, be sure to tell them how to rename them so they can get their normal versions (this may also work on Windows except it refuses if the program is running).
Although I certainly agree that single application directory is the way to go, I have not found OS/X all that easy.
At least for me, everything I have tried to install involves the following steps:
1. Download the file to the desktop. 2. The file is a.dmg, double click it. 3. A mysterious disk is created and the damn gui gives no hint as to the pathname so I can't peek into it using the shell. In any case, typically the window opens showing the disk contents (though I have at least once had to locate the disk on my desktop and double-click it myself). 4a. *maybe* there is that great application folder in there and I can drag it to applications. I can also double-click it right there and try it, a great idea that you failed to mention. In at least one case (LAME) I have not been able to get the program to work after dragging the file anywhere, I always have to reopen the dmg and double-click it there. 4b. More likely, there is a.pkg file there, I have to double-click that and it gives me dialogs, and it could very well be doing more mysterious things than putting the app in/Applications. This, you will notice, is the same starting place most Windows users are in after downloading a file. 5. After installing, I am left with a.dmg and a disk, and am unsure if I can throw them away or not.
Now perhaps I am an idiot and am somehow using this wrong. And it is obvious that the underlying design could really be made easy. But for some reason the Mac software is not practicing what it preaches. The only technical reason I can see is the lack of a standard for downloading an already-working populated directory tree.
Which brings me to: influence. Very few projects at Microsoft have "small" impact. Everywhere you turn, the projects people are working on are likely to be used by thousands or millions of people. It's an awesome responsibility, but an awesome chance to create widely influential software.
Although he is trying to sell how good Microsoft is, he has inadvertantly stated exactly the source of the evil. It is not management or some plan to wipe out everybody by being incompatable. It in instead exactly this, the excitement of knowing you are controlling a few million users, and that deep part of your brain, that if you break the competitor's product, you will gain another hundred thousand, and it goes to your head. This combined with the fact that it is much easier to just write something without referring to any standards (something OSS has problems with, too) means there is a huge subconcious push to write the most evil software possible.
I also think any company in the same position would be just as evil. IBM was. RedHat would be (some are worried that they already are in the Linux sector). IBM could easily be again. Apple could. Microsoft sounds like they are not overburdened with management, and that if they were below 50% market share, they would probably turn into one of the most benificial companies so fast that nobody would believe it, as suddenly the only way to "influence millions of people" is to start making your code work with the stuff those people are using, rather than forcing them to change exclusively to your stuff.
It probably should be called "open" as that is what OS/X uses.
Windows uses "start" but in fact that is not a program but a built-in shell command, apparently. The command "rundll32.exe url.dll,FileProtocolHandler" is what really works on Windows. If you assumme firefox is installed, the command "firefox" works pretty good on Linux but really that is not exactly what is wanted.
These ideas all sound good, I just don't want it built into the shell because I want multiple shells, and also any desktop environments, to be able to call it. I guess you are right it does not have to be the exec() call, that was just an idea I had to make it somewhat back-compatable with any existing file-browsing programs (but now that I think about it, they probably check the exec bit before calling exec, so this probably won't help).
An alternative is to have a well-defined command in the path, perhaps called "open" or "start" that does the correct thing with the file given to it as an argument. Without any change then, a user can type "open README" and get the desired effect, and all file browser can be changed to exec("open",name,0). To fix it so just "README" works, the shell should be rewritten: if there are no slashes in the word it should search the path for the first match that is executable, and if that fails or there are slashes in the word, it just expands it and checks if the file exists. If the executable bit is on, it probably should run it as before (so output goes to the same terminal). Otherwise it should call "open" with it, passing open the entire command line as argv.
The "open" command would also check for the executable bit and try exec() on the files as well, however it would create i/o windows if the program tries to do stdin/out. If the executable bit is not on it will instead use mime/file/magic bytes to figure out what program to run. Any forking would be done by the open program, failures would cause it to popup an error message and then exit with an error code after the user dismisses the box. Open should be required to figure out what program to exec in a short time (like less than a second) so that forking/background is not needed until the program is launched.
Unfortunatly something has to be built into the shell so you don't have to type a command before the file. Having the result be to run some other program with the filename as an argument is probably a good way to implement it, however.
It does seem like it would be an easy modification to any shell.
"view README" requires you to type the word "view" and does not do the same thing as double-clicking in a GUI file browser. For instance it does not work on non-text files. And it's vi, which is not very user friendly, even I got stumped for awhile trying to exit it (for some reason the first colon did nothing).
I would make any file be a command (in your ls case, both "ls" and "lsabc" are valid completions, so depending on how the tab completion is implemented you may get the filename, this happens with directories in shells already and has not caused too much difficulty). Running a file must do exactly the same thing as double-clicking it in a gui file browser. Executable files with the same name in the path take precedence, so a file called "ls" in your current directory would not stop you from running "ls", and you could always type "./ls" to get the file. Switches or any other words typed after the filename are passed to the program that is chosen to run, so "README -print" could run the print command, or something like that.
I really don't think there is any need to turn this off, modes are bad.
Initially the shell could just be fixed to run some program with the filename as argument and that program can be changed by your KDE/Gnome/Whatever desktop preference, but that would be a hack just to get it to work. In the future the glibc/kernel or whatever would be altered so that exec() works for any file, thus moving all this machinery for choosing what to do out of the "desktop environment" and into the system where it should be.
If Microsoft users could easily locate the correct conference room on the Microsoft campus and walk into a meeting and ask questions, I'm sure they would be yelled at plenty and told to get out the meetings and rtfm. It would actually be worse if often enough somebody at the meeting, instead of yelling, would say "oh yea I know what that is, you do this and this to fix it" and thus answered the question 100 times faster than any other method, thus encouraging the user to face the abuse because the odds are that the results will be better.
Microsoft does not have this problem because you need to get past security to get into the conference room. Linux can't implement this because people will just say they are getting *more* snobbish.
But there is a more important problem. In Linux it literally is 1000 or more times easier to find and walk into that conference room than to find the documentation or call the support line. Real, usable documentation has got to be easily locatable, just by knowing the name of the program you are trying to use. Unfortunatley "man" pages are still the best, if "man xyz" does not say "no documentation available" it will actually produce the information I need. I have yet to see this with any html system or google where you can spend hours searching (ie a clear "you will not find what you are looking for" would help).
Also the command line needs some work. It is not unfriendly because it is not a GUI, but because it is lacking some stuff that too many programmers think is "gui stuff". A previous poster complained about the difficulty in telling somebody how to read a README, getting them stuck in less or vi. But the "noobie" apparently was able to locate the README file easily using the command line. They knew it was there, but not how to read it. They were told "try vim or cat or less", but that is just stupid. Why doesn't the command line let you type the name of the damn file (ie type "README") and it then acts exactly like those GUIs and open the file in the GUI text editor. Too many idiots think that somehow this function is impossible unless there is a mouse and you push the button twice. Get with it.,
Microsoft will NOT allow dual-boot machines. This was used to kill BeoS and OS2. Apple selling their own hardware does not bother them, but they would then have to allow people to sell dual-boot Windows/Linux machines, and they will not do this ever.
I'm going to patent the idea of writing "mod me down because I said something good about Microsoft or Windows, or because I said something bad about Linux / Apple" in a Slashdot post as a way of raising mod points. I think at least half the posters here will own me patent license fees.
Except for panels such as the file browser and print setup, and other popups like error messages and alerts, etc, people probably would never notice if they are running a Gnome or KDE program on either desktop. The differences in GUI between the toolkits are miniscule due to them copying each other and copying Windows (and Windows is only "consistent" because the toolkits there copy each other, there are in fact many *more* different GUI toolkits used on Windows than Linux).
I would like to see a Unix-style solution to this mess, which is to have small programs do each job. In the file chooser case, any program wanting to popup a file chooser would do something like exec("file_chooser", args...) and wait for it to exit. Exit with an error means the user hit cancel. Exit with success and the program will print the chosen filename to stdout. Existing toolkits would be modified to do this, scrapping their filechooser code.
This would allow people to experiment with new designs of file choosers. This would, within a few months, make Linux have the best file chooser in the world, as opposed to being in last place as it is now. Also practically, the file chooser program could lauch and keep a process running, allowing all the read directories and all the icons and thumbnails and user preferences to be already loaded and cached and shared between every file chooser, rather than the obscene overhead that exists now. It would allow all programs to instantly integrate into KDE/Gnome/XFCE because they all call the same file chooser and other popup panels.
Even today there is a lot of precedence. After a long line of crap, it is becoming accepted to display a web resource by running "firefox ", rather than running the toolkit's html preview widget. There is already a program called "dialog" or "kdialog" that does a very limited version, though people seem to think this is only for shell scripts, but nothing keeps programs with no tookit from exec'ing it.
I would like to see some sign that the freedesktop.org guys are considering this, but have not seen anything. Really sad and scary, as they are killing the biggest advantage Linux has or could have over other systems.
For something to be "intuitive", the user needs to be able to divine its existence and/or behaviour based on knowledge they already have of how the system works.
I think I'm not explaining things right. The reason is would be "intuitive" is precisely that, that it would be easy for a user to "device it's existence based on knowledge they already have of how the system works". This is because it would always work, no matter where you clicked the "menu" button, that it would bring up the contextual menu.
They would be "intuitive" and "discoverable" if every program used them and thus users expected them, and thus they learned they could right-click on anything to see the menu and see what is on it. It would also help if the word "menu" was printed on the mouse button.
I would use the right-hand mouse button to pop up menus. For global stuff, either point at an empty area of desktop, or use a global shift key that also modifies the other mouse clicks to move and rearrange windows. This global menu would contain the entire contents of the Windows "start" menu and the taskbar, thus allowing you to launch any program or switch to any running one. Global shortcuts to get any of these actions would be displayed on the menu as well.
The design of the menus themselves would be much better than what people are used to seeing. A change I would insist on is that they pop up with the mouse pointing at the previously picked item. More complex changes are to alter the layout to circular and to make changes to the navigation methods. If popup menus were standardized I'm sure a lot of innovation would have been done in this area and ideas that nobody has thought of yet would be common.
The problem is that the thing you want may still be on the portion of the taskbar that is in the other monitor. One solution is to duplicate the entire contents, but that looks silly. The other solution (and to the top-menu-bar) would be pop-up menus, unfortunatly the luddites have made sure that everybody thinks they are not user-friendly.
Arguing that Linux (or Windows) is better is NOT FUD!!!
Unfortunatly far too many stupid people on all sides of the arguments here think FUD means "an argument about why A is better than B from somebody who likes A". That is NOT "FUD". It does not matter if the argument is true, false, indeterminate, or incredibly silly. It still is not "FUD".
FUD is "an argument about why buying B instead of A is going to cause you pain and suffering, irregardless of whether A or B is better otherwise". Again it is entirely unimportant whether the argument is true, false, mixed, or silly. That is FUD.
About the only "FUD" I have seen from the Linux side is things like the original post, along the lines of "it will be the downfall of computerized civilization unless you stop buying Microsoft". (unfortunatly that isn't very strong fud, as even if you believe it you would figure that civilization will fall anyway because too many other people are buying Microsoft).
Plenty of people label anything from Microsoft "FUD", and that is wrong. Saying "Windows is a much better and faster and more secure and perfect OS than Linux could ever hope to be" is NOT "FUD". Saying "we might in the future sue you if you look at Linux" *IS* "FUD". Learn the difference.
Slashdot Mirror
Note that this apperent "newbie" knows there are things called "libraries" and that they reside on the disk, and perhaps knows that they are needed to run programs. He also has no problem with the fact that clicking around in the file chooser you can visit a folder called "windows/system32" and see the "libraries" there. He then goes on to praise this all as user-friendly and the way it should be.
On Linux, he either knew (or guessed correctly) that there are also things called "libraries". However they are in a directory called "/usr/local/lib". And by clicking around in the file chooser, you can see that. Yet somehow this is considered a horrible user-hostile thing on Linux!
It should be pretty obvious that the ideas are absolutely identical, except the names are changed. The problem is that people are absolutly used to Windows and have learned quite a lot of detail about how it works, perhaps a suprising amount, that even they will claim they don't know. This is exactly like your inability to use Windows until a copy of tcsh is installed, even if you only use it to run programs that you could type into cmd.exe or the "run box". Familiarity completely masks the fact that the level of complexity is identical, instead the familiar one feels as easy as breathing, while the unknown one is shown in it's exact complexity.
The solution may be to live with emulating Windows more. The problem here is that Window file layout is really bad. Still, where Linux is obviously better (having a home directory with your personal settings inside it) it seems even newbies pick it up. But putting everything else in capitalized-named directories in the root may be a huge barrier fix. Then again I may be underestimating, perhaps everything has to be put in directories named "Programs and Documents" and "windows32" because those are the "intuitive" and "obvious" names.
The obvious problem is that Unix users are used to the current mess, and make excuses for the multiple locations that are long obsolete (such as read-only file systems). Besides it can be emulated with symlinks. The less obvious problem is that some Linux developers actually believe all those Windows users who say they can use a computer without "knowing anything", so they feel there is no need to change the names of these directories since that is a system detail that a "newbie" obviously does not know. But, as the above poster shows, the "newbie" does in fact know this in elaborate detail, even if they don't know "why" it works that way, they know elaborate details about Windows and cannot stand it being too different.
The article would be more accurate if it said "This was caused by something as seemingly harmless as a missing closing parenthesis, plus the unfortunate loss of an open parenthesis that caused this mistake to not be detected by the compiler"
I just checked, and stupid gcc does not produce any warning whatsoever. I tried it as C++, I tried -Wall and -W, and still nothing. Not a good showing there.
I think the proper warning is that the test is constant. "geteuid != 0" is always true.
I remember seeing in 1986 or so, a 300-dpi crt monitor. It was monochrome, and probably only 1-bit/pixel, and was page-oriented (taller than wide). However it seemed pretty impressive, as it was exactly the same resolution as the laser printers at that time, and using monochrome 1-bit/pixel was still pretty common at that time. This was at a trade show (siggraph?). Certainly it would seem very useful to somebody writing documents, or reading them.
Anyway it's pretty obvious that idea was a dead end. I'm sure there were technical problems in that software had to be rewritten to use it. I'm sure the lack of color was a problem (and could not be solved, as crt color masks can't be made that resolution). But still it sounds like it would be useful, but never saw it in the real world.
Some other people made comments that the problem is that programs specify font sizes in pixels instead of points or something. This is misleading. Both X and Windows actually did specify fonts in "points", the problem is that *everything else*, such as lines and boxes, were specified in pixels. Trying to draw in two different coordinate systems with an almost arbitrary relationship is impossible, so programs would break badly when you went to a different system with a different DPI. Windows initially fixed this by allowing font sizes to be negative to indicate size in pixels, and then finally (win95 or 8?) just fixed the scale between "points" and "pixels" to be 4/3, ignoring the DPI resolution. X has still not figured this out and you still get screwed up output if you plug in the wrong monitor, but the newest api (Cairo) does get rid of specifying fonts in anything other than the same units as drawing, *finally*!!!
Replacing the DLL's is a BAD idea, and I think all newer Windows installs don't do this. You can put the needed copy of the DLL in your application directory itself, just as the original poster suggested. Don't put anything in there that seems to be provided by default (easily tested by trying to run your software on a non-development machine) Though occasionally I have had an end user need some mysterious xyzzy32.dll and had to direct them to the net to get it (all I can guess is that they threw their copy away or some virus did it), the base functions seem to be consistently provided on all versions of Windows, and the bundled .dll's are typically very application specific and not provided by Microsoft (so there won't be any automatic patching of them anyway).
The same solution can work for Linux. There is a switch to the linker (-Wl,--rpath,'${ORIGIN}' passed to g++) that makes it look in the executable directory for libraries. (in addition, readlink("/proc/self/exe") can get the information that should be in argv[0] so you can locate files other than libraries). To figure out what libraries you need to include, just like Windows, try running on a non-development machine, perhaps a different distribution.
The problem with Linux is that there is a little less stuff in the base, such as a version of Qt or gtk that is likely to link with your program. And these things are truly huge, it would be like including an entire copy of Windows with a windows app. My solution is to use fltk, statically linked, but that may not fly with all developers. If you do include large libraries, be sure to tell them how to rename them so they can get their normal versions (this may also work on Windows except it refuses if the program is running).
Although I certainly agree that single application directory is the way to go, I have not found OS/X all that easy.
.dmg, double click it. .pkg file there, I have to double-click that and it gives me dialogs, and it could very well be doing more mysterious things than putting the app in /Applications. This, you will notice, is the same starting place most Windows users are in after downloading a file. .dmg and a disk, and am unsure if I can throw them away or not.
At least for me, everything I have tried to install involves the following steps:
1. Download the file to the desktop.
2. The file is a
3. A mysterious disk is created and the damn gui gives no hint as to the pathname so I can't peek into it using the shell. In any case, typically the window opens showing the disk contents (though I have at least once had to locate the disk on my desktop and double-click it myself).
4a. *maybe* there is that great application folder in there and I can drag it to applications. I can also double-click it right there and try it, a great idea that you failed to mention. In at least one case (LAME) I have not been able to get the program to work after dragging the file anywhere, I always have to reopen the dmg and double-click it there.
4b. More likely, there is a
5. After installing, I am left with a
Now perhaps I am an idiot and am somehow using this wrong. And it is obvious that the underlying design could really be made easy. But for some reason the Mac software is not practicing what it preaches. The only technical reason I can see is the lack of a standard for downloading an already-working populated directory tree.
You think the Wine developers don't know how to write a program for the Windows API?
Which brings me to: influence. Very few projects at Microsoft have "small" impact. Everywhere you turn, the projects people are working on are likely to be used by thousands or millions of people. It's an awesome responsibility, but an awesome chance to create widely influential software.
Although he is trying to sell how good Microsoft is, he has inadvertantly stated exactly the source of the evil. It is not management or some plan to wipe out everybody by being incompatable. It in instead exactly this, the excitement of knowing you are controlling a few million users, and that deep part of your brain, that if you break the competitor's product, you will gain another hundred thousand, and it goes to your head. This combined with the fact that it is much easier to just write something without referring to any standards (something OSS has problems with, too) means there is a huge subconcious push to write the most evil software possible.
I also think any company in the same position would be just as evil. IBM was. RedHat would be (some are worried that they already are in the Linux sector). IBM could easily be again. Apple could. Microsoft sounds like they are not overburdened with management, and that if they were below 50% market share, they would probably turn into one of the most benificial companies so fast that nobody would believe it, as suddenly the only way to "influence millions of people" is to start making your code work with the stuff those people are using, rather than forcing them to change exclusively to your stuff.
It probably should be called "open" as that is what OS/X uses.
Windows uses "start" but in fact that is not a program but a built-in shell command, apparently. The command "rundll32.exe url.dll,FileProtocolHandler" is what really works on Windows. If you assumme firefox is installed, the command "firefox" works pretty good on Linux but really that is not exactly what is wanted.
These ideas all sound good, I just don't want it built into the shell because I want multiple shells, and also any desktop environments, to be able to call it. I guess you are right it does not have to be the exec() call, that was just an idea I had to make it somewhat back-compatable with any existing file-browsing programs (but now that I think about it, they probably check the exec bit before calling exec, so this probably won't help).
An alternative is to have a well-defined command in the path, perhaps called "open" or "start" that does the correct thing with the file given to it as an argument. Without any change then, a user can type "open README" and get the desired effect, and all file browser can be changed to exec("open",name,0). To fix it so just "README" works, the shell should be rewritten: if there are no slashes in the word it should search the path for the first match that is executable, and if that fails or there are slashes in the word, it just expands it and checks if the file exists. If the executable bit is on, it probably should run it as before (so output goes to the same terminal). Otherwise it should call "open" with it, passing open the entire command line as argv.
The "open" command would also check for the executable bit and try exec() on the files as well, however it would create i/o windows if the program tries to do stdin/out. If the executable bit is not on it will instead use mime/file/magic bytes to figure out what program to run. Any forking would be done by the open program, failures would cause it to popup an error message and then exit with an error code after the user dismisses the box. Open should be required to figure out what program to exec in a short time (like less than a second) so that forking/background is not needed until the program is launched.
Unfortunatly something has to be built into the shell so you don't have to type a command before the file. Having the result be to run some other program with the filename as an argument is probably a good way to implement it, however.
It does seem like it would be an easy modification to any shell.
"view README" requires you to type the word "view" and does not do the same thing as double-clicking in a GUI file browser. For instance it does not work on non-text files. And it's vi, which is not very user friendly, even I got stumped for awhile trying to exit it (for some reason the first colon did nothing).
I would make any file be a command (in your ls case, both "ls" and "lsabc" are valid completions, so depending on how the tab completion is implemented you may get the filename, this happens with directories in shells already and has not caused too much difficulty). Running a file must do exactly the same thing as double-clicking it in a gui file browser. Executable files with the same name in the path take precedence, so a file called "ls" in your current directory would not stop you from running "ls", and you could always type "./ls" to get the file. Switches or any other words typed after the filename are passed to the program that is chosen to run, so "README -print" could run the print command, or something like that.
I really don't think there is any need to turn this off, modes are bad.
Initially the shell could just be fixed to run some program with the filename as argument and that program can be changed by your KDE/Gnome/Whatever desktop preference, but that would be a hack just to get it to work. In the future the glibc/kernel or whatever would be altered so that exec() works for any file, thus moving all this machinery for choosing what to do out of the "desktop environment" and into the system where it should be.
If Microsoft users could easily locate the correct conference room on the Microsoft campus and walk into a meeting and ask questions, I'm sure they would be yelled at plenty and told to get out the meetings and rtfm. It would actually be worse if often enough somebody at the meeting, instead of yelling, would say "oh yea I know what that is, you do this and this to fix it" and thus answered the question 100 times faster than any other method, thus encouraging the user to face the abuse because the odds are that the results will be better.
Microsoft does not have this problem because you need to get past security to get into the conference room. Linux can't implement this because people will just say they are getting *more* snobbish.
But there is a more important problem. In Linux it literally is 1000 or more times easier to find and walk into that conference room than to find the documentation or call the support line. Real, usable documentation has got to be easily locatable, just by knowing the name of the program you are trying to use. Unfortunatley "man" pages are still the best, if "man xyz" does not say "no documentation available" it will actually produce the information I need. I have yet to see this with any html system or google where you can spend hours searching (ie a clear "you will not find what you are looking for" would help).
Also the command line needs some work. It is not unfriendly because it is not a GUI, but because it is lacking some stuff that too many programmers think is "gui stuff". A previous poster complained about the difficulty in telling somebody how to read a README, getting them stuck in less or vi. But the "noobie" apparently was able to locate the README file easily using the command line. They knew it was there, but not how to read it. They were told "try vim or cat or less", but that is just stupid. Why doesn't the command line let you type the name of the damn file (ie type "README") and it then acts exactly like those GUIs and open the file in the GUI text editor. Too many idiots think that somehow this function is impossible unless there is a mouse and you push the button twice. Get with it.,
Microsoft will NOT allow dual-boot machines. This was used to kill BeoS and OS2. Apple selling their own hardware does not bother them, but they would then have to allow people to sell dual-boot Windows/Linux machines, and they will not do this ever.
I'm going to patent the idea of writing "mod me down because I said something good about Microsoft or Windows, or because I said something bad about Linux / Apple" in a Slashdot post as a way of raising mod points. I think at least half the posters here will own me patent license fees.
Not likely. Only one program is needed to show icons on the desktop, so this is not an interoperation thing.
Except for panels such as the file browser and print setup, and other popups like error messages and alerts, etc, people probably would never notice if they are running a Gnome or KDE program on either desktop. The differences in GUI between the toolkits are miniscule due to them copying each other and copying Windows (and Windows is only "consistent" because the toolkits there copy each other, there are in fact many *more* different GUI toolkits used on Windows than Linux).
I would like to see a Unix-style solution to this mess, which is to have small programs do each job. In the file chooser case, any program wanting to popup a file chooser would do something like exec("file_chooser", args...) and wait for it to exit. Exit with an error means the user hit cancel. Exit with success and the program will print the chosen filename to stdout. Existing toolkits would be modified to do this, scrapping their filechooser code.
This would allow people to experiment with new designs of file choosers. This would, within a few months, make Linux have the best file chooser in the world, as opposed to being in last place as it is now. Also practically, the file chooser program could lauch and keep a process running, allowing all the read directories and all the icons and thumbnails and user preferences to be already loaded and cached and shared between every file chooser, rather than the obscene overhead that exists now. It would allow all programs to instantly integrate into KDE/Gnome/XFCE because they all call the same file chooser and other popup panels.
Even today there is a lot of precedence. After a long line of crap, it is becoming accepted to display a web resource by running "firefox ", rather than running the toolkit's html preview widget. There is already a program called "dialog" or "kdialog" that does a very limited version, though people seem to think this is only for shell scripts, but nothing keeps programs with no tookit from exec'ing it.
I would like to see some sign that the freedesktop.org guys are considering this, but have not seen anything. Really sad and scary, as they are killing the biggest advantage Linux has or could have over other systems.
Gosh, if "everybody believed in global cooling" back in 1974, you would think there would be more than one article, wouldn't you?
For something to be "intuitive", the user needs to be able to divine its existence and/or behaviour based on knowledge they already have of how the system works.
I think I'm not explaining things right. The reason is would be "intuitive" is precisely that, that it would be easy for a user to "device it's existence based on knowledge they already have of how the system works". This is because it would always work, no matter where you clicked the "menu" button, that it would bring up the contextual menu.
They would be "intuitive" and "discoverable" if every program used them and thus users expected them, and thus they learned they could right-click on anything to see the menu and see what is on it. It would also help if the word "menu" was printed on the mouse button.
I would use the right-hand mouse button to pop up menus. For global stuff, either point at an empty area of desktop, or use a global shift key that also modifies the other mouse clicks to move and rearrange windows. This global menu would contain the entire contents of the Windows "start" menu and the taskbar, thus allowing you to launch any program or switch to any running one. Global shortcuts to get any of these actions would be displayed on the menu as well.
The design of the menus themselves would be much better than what people are used to seeing. A change I would insist on is that they pop up with the mouse pointing at the previously picked item. More complex changes are to alter the layout to circular and to make changes to the navigation methods. If popup menus were standardized I'm sure a lot of innovation would have been done in this area and ideas that nobody has thought of yet would be common.
The problem is that the thing you want may still be on the portion of the taskbar that is in the other monitor. One solution is to duplicate the entire contents, but that looks silly. The other solution (and to the top-menu-bar) would be pop-up menus, unfortunatly the luddites have made sure that everybody thinks they are not user-friendly.
The extension should not be required to communicate. Otherwise it isn't really an "extension".
Arguing that Linux (or Windows) is better is NOT FUD!!!
Unfortunatly far too many stupid people on all sides of the arguments here think FUD means "an argument about why A is better than B from somebody who likes A". That is NOT "FUD". It does not matter if the argument is true, false, indeterminate, or incredibly silly. It still is not "FUD".
FUD is "an argument about why buying B instead of A is going to cause you pain and suffering, irregardless of whether A or B is better otherwise". Again it is entirely unimportant whether the argument is true, false, mixed, or silly. That is FUD.
About the only "FUD" I have seen from the Linux side is things like the original post, along the lines of "it will be the downfall of computerized civilization unless you stop buying Microsoft". (unfortunatly that isn't very strong fud, as even if you believe it you would figure that civilization will fall anyway because too many other people are buying Microsoft).
Plenty of people label anything from Microsoft "FUD", and that is wrong. Saying "Windows is a much better and faster and more secure and perfect OS than Linux could ever hope to be" is NOT "FUD". Saying "we might in the future sue you if you look at Linux" *IS* "FUD". Learn the difference.