True, programs should read the Xresources, and I think both GTK and Qt are making a big mistake by not doing so.
The X resources are stored with the server, which is very useful for getting the interface correct when you can run remote applications. In addition they allow the resources to be different per application, something none of the theme systems seem to address.
However I very much disagree with the way Motif used it, where they turned it into a huge database that could not be programmed without intricate knowledge of the innards of the application (and often where the program was unusable unless several hundred correctly-set fields were in the database). I also disagree with their inane attempt to merge several (eventually dozens) of files by the application to get the database (ie the "appdefaults", searching for ".Xresources", etc) rather than leaving this to another program and only using the resources string from the server.
The X resources should be on the level of the Win32 preferences settings, very general like they were intended when X was designed, things like "text background color". Not the Motif scheme where the color of every single button can be set individually. This sounds powerful, but is actually totally useless to any real user and makes the database obscenely complex.
Basically Qt and GTK get it wrong by not reading their settings from the database, and Motif got it wrong by turning the database into a Windows-like "registry" with all the bugs needed.
PS: You can easily emulate the X defaults on Windows, just read them from a file! You should also read the Win32 preference settings, it should be trivial to make the toolkit #ifdef in some code for this at the same point it reads the X defaults. With the design specified above there should be no reason to use the Xt or Xrdb functions, just parse the string yourself.
No I got the point exactly. The claim is that of those 40,000 applications, exactly one (MS Office) could allow perhaps 10-20% people to use Linux instead, versus the perhaps 5% now. It may allow almost 100% of normal office workers to use Linux. Such percentage gains would perhaps encourage the porting of other programs and snowball into getting the vast majority of programs to work on Linux (or at least encourage them to test it under Wine).
The point is that the weight of importance of the applications is not equal. The importance is so unequal that you might as well ignore all those other 39,999 applications!
PS: I would also add Quicken to the necessary list. People seem to ignore this because it is not "evil MicroSoft" and it is believed it would be trivial to port it if they ever decided to.
I think you missed the point of the letter. He is well aware that there are 40,000 applications that don't work on Linux, but the claim is that there is only one that is important, which is MS Office.
Yea you can worry about those apps being sent to you by regulatory agencies, but for the vast majority of people, the only thing they are sent that does not work on Linux is MS Word documents and Excel spreadsheets.
It should not be exceptionally difficult to make old X programs work anyway, by making an Xlib replacement that translates the calls and throws away things that cannot be done on the new system. The only X programs that would not work would be window managers. This should be vastly easier than making WINE work. You could also make an "X server" that uses this library so remote X applications work.
There are about a dozen viable replacements (I like the look of DirectFB, but Atheos looks pretty good too though it may have the toolkit problem described below).
There are a few problems with the replacements, though. First is that they often throw out the client/server model and rely on shared memory. In my opinion this eliminates the one good thing about X, which is that programs from many sources can share the screen. I also think client/server can be far faster than shared memory, due to the triviality of making it multithreaded. The problem with X that causes these shared memory ideas is that X has far too many "synchronous" calls, where the call has a return value. The interface needs to be designed to by almost entirely asynchronous, so that thousands of calls can be batched together into a single context switch.
The other problem is too many of the replacements try to force a "toolkit" on the programmer. This is like trying to make a file system that requires you to use MySQL to do all possible manipulations of the files. It is too high level, complex and thus potentially buggy, and it forces you to use current-day designs and precludes any innovation.
Re:Impressionist FUD can be a serious problem!
on
Shared Source?
·
· Score: 2
Developers would not copy GPL licensed code into applications that were not meant to be GPL any more than
they would copy Microsoft Shared Source into a Program without Licensing the code from Microsoft for use. In either
case, you would be in violation of Copyright law.
Excellent description of the equivalence. If GPL is "viral" then their own code is "viral". This point needs to be hammered home, there are people here on slashdot that show amazing ignorance of this, you can imagine what people in the real world think!
You can write all the code you want and not put it under the GPL, and can sell it for whatever you want!
Oh, boo hoo, you can't take the source code with Linux and turn it into your own profit-making program. I'm just so sad for you. Hey, do you think you can take MicroSoft's code and turn it into a profit-making program without MicroSoft having something mean to say to you?
Have you heard of the LGPL? I think you will find that almost all equivalents of MicroSoft's "libraries" are covered under the LGPL, which specifically allows exactly this.
LGPL is more free than MicroSoft's libraries because besides the ability to use it in closed programs, you can also make derivative libraries (which must be open source, like GPL programs).
Now not everything is rosey:
1. The LGPL has some strange wording that makes many people think the libraries have to be shared. I personally don't think so, but this belief puts a lot of annoying requirements on the library, and requires "installation" and "dll hell" for programs that use them. Rather than question this we have modified the LGPL to specifically say that static linking is allowed.
2. RMS has a strange idea that putting libraries under the GPL will force people to make the programs under the GPL due to the "virii" nature. This is absurdly untrue, the result is that people don't use the library at all, and they then use a commercial library that runs only on platforms that are made by large Seattle companies whose name starts with M. Putting useful libraries under GPL licenses is seriously hurting the acceptance of Linux as it is stopping the creation of commercial programs that port to Linux. Fortunately most everybody else appears to disagree with RMS and use the LGPL or Berkely licenses for libraries.
Instead of the complex graphics, why not work on getting it so any program (using open/close/seek) can read/write any data stream. I would love to be able to "cat http://blah.blah/index.html" without a special version of "cat".
I can't understand why anybody would consider any technique for naming information sources that does not cause open/close/seek to be able to manipulate those sources. Requiring this "vfs library" goes completely against the Unix design.
I would much rather see effort going into creating such easy to use programming interfaces, rather than these huge bloated libraries with interfaces that make MicroSoft's stuff look acceptable, and copies of MicroSofts rather lame ideas for GUI. The killer apps are going to come out of some teenager's basement, but only if the power in the system is accessible by mortals, and this is only going to happen if it is simple enough to be understood without years of study.
On my machine it creates a file that contains the text "link to blahblahblah" or something like that. It is not clear what program libraries obey this.
This may be true on newer NT systems (this was NT4.0). However the lack of symbolic links (which should be trivial to implement compared to hard ones) is still glaringly obvious.
Okay, the files should be of the form [name].[extension]. [name] is a user friendly name, ie something that a person of average intelligence may type, like "Helvetica". An example of a non-user-friendly name, which is not allowed under my design, is "adobe-helvetica-bold-normal-p".
[extension] is the user-unfriendly part and each font using service looks for a set of extensions it understands. Examples are "pfa", "ttf", and maybe "xfont.25.25" for an x bitmapped font that is designed for a pixel size of 25 vertically and 25 horizontally.
Somebody asked about designing it. Well here goes:
Fonts are stored in/usr/share/fonts and/usr/local/share/fonts. FreeType, GhostScript, X, and all other programs that load fonts are modified to look for all their files there.
The files are all of the form.. is a USER FRIENDLY name that can easily be typed and rememberd. The extension is used to distinguish various incompatable font formats, or different transformatons of image-based font formats. Systems that don't understand an extension ignore those files as though they are not there.
Fonts may also be stored in subdirectories, but in this case the "name" has slashes in it, so the services can just consider them normal file names.
Font files are found by a service taking the user-friendly name (X servers will have to extract a few fields from the ugly X name to get this) and tacking on each extension the service understands and checking if the file is there. There is no need to use readdir to get a specific named font. Services can assumme that once they see a font, that file will not be changed or disappear, although they may want to check the date stamp every now or then.
Services that need to search for fonts will have to recursively readdir the entire directory tree. They should be written so they don't do this on startup but instead delay it at least until the first font is requested. They should record the datestamp of the root directories and rerun the search if it has changed. Services are allowed to create their own cache files but they should create them in some other directory, as they may have read-only access to the font directories.
Multiple names for the same font (like "Ariel" or "helvetica" for "Helvetica") are done with symbolic links.
Yes it is quite likely that the first implementations will ignore each other's fonts. I expect they will gradually start to read each other, and that obsolete formats will disappear, and eventually there will be one file for each font.
Uh, no, cygwin ln does not do this, it just does not work.
You can make symbolic links, but only programs that use the cygwin libraries works with them, which makes them pretty close to useless.
PS: symbolic links would be much more useful (I'm sure there are many people who think hard links are a mistake in Unix design and symbolic links should be used everywhere), and could easily be implemented in NT (or any other system) without affecting the file system, as long as there is space for one bit that can be set on each file entry (to indicate that it is a symbolic link). The reason MicroSoft does not support them is obvious: it would instantly allow interoperability with Unix because you could eliminate the drive letters and make things like home directories appear in the "Unix" locations without breaking any Windows software. Actions like this, much more than "secret interfaces" (which are really the result of incompetent programmers who don't document what they are writing, than of some evil conspiracy) are a much clearer indication of how much MicroSoft wants to disallow interoperability. MSDOS had a simple symbolic link (the destination had to be a disk) called "assign", this was conspicuously deleted from newer versions of the system. From my own experience with writing portable software, the drive letters are a bigger hinderance to interoperation than anything having to do with GUI.
You are still not making any sense. The Encarta entry IS the source code, and so is the rest of your paper, thus you have given the "user" (whoever you turned the paper in to) the source code.
Again, please give an example of SOURCE CODE for a PRODUCT and stop trying to change the rules to weasel out of this!
I do think people saying things as stupid as you did hurt any attempt to have a reasonable attempt to argue against the GPL. I myself am having trouble with the GPL but we need logical arguments to suggest there may be alternatives. Spewing stuff about "the GPL is not free" is like calling people communists or nazis, or calling everybody at MicroSoft evil. It does not convince anybody and makes you look like a fool.
Did you read my post? I specifically said not to count "code examples".
Can you give an example of a product (ie sold for money, or considered of significant added value when bundled with Windows) made by MicroSoft where they allow you to use the source code in your own product where you are not required to return some compensation to MicroSoft.
PS: in case you are wondering, I don't consider the GPL all that great. I have used the LGPL for my code, but I am changing it to specifically allow static-linked closed source executables, because I believe that the GPL's prevention of closed-source products is a detriment to it's use and adoption. However I don't think people should say obviously stupid things like "MicroSoft's software is more free" as it harms any kind of meaningful discussion.
Every IBM PC text-mode program I ever saw used Alt+letter (and the numbered function keys) as shortcuts. Control+letter either did nothing or acted like Emacs, or inserted funny card symbols from the IBM character set. If you can find any program that used Ctrl+C for copy before Windows95 I would like to see it.
Text-mode Microsoft word used Alt exclusively for all the menus. Control ran their own strange keybindings and I don't think it used Ctrl+C for copy (they used that Shift+Delete idea).
Certainly the first Windows programs (I worked with the tiled version of Windows, before 3.1) did not reserve Alt for shortcuts to bring down menus. There was no such concept. The underscores did not show up until Windows 93. You were certainly allowed to use Alt+letter in the menus (I did this in my Windows programs), I don't know if the underscores took precedence as I never used them.
I also have never seen an X program that used Ctrl to act like the Mac before about 1995, but plenty that used Alt. I would think if this was a MicroSoft standard for Windows93 there would have been at least one example.
The Emacs bindings do not conflict with reasonable use of Ctrl, IMHO. I prefer a combination of MS style ZXCV and Emacs bindings for all the other keys. The fact that there is no shortcut for start/end of line is pretty inexcusable, and making ^A select all text has caused me to lose untold amounts of work because I type it by accident all the time.
I don't consider the GPL free, as it has a licence far more restrictive than anything Microsoft has ever dreamed up
Now that is just being stupid. I would like you to point out a single example where MicroSoft allowed anybody to use their source code in a closed-source product without returning something to MicroSoft.
Too many ignorant people don't realize that code can be released under multiple licenses. Therefore, if I write some GPL code, I may be willing to sell it to you for a price for use in your closed-source product. You can also take the GPL code and use it in an open-source product. As far as I can tell this means you can do more with the GPL code than you can with any MicroSoft code.
And don't go saying the code examples in the MicroSoft manuals are free of any encumberances. So are the code examples provided with GCC! Boy can people be thick sometimes...
"Easy installation" does not mean binaries are required. Why not come up with an "easy installation" that compiles the program?
Ie when you double-click the "install this" it runs the compiler as necessary.
I don't think anybody cares how long it takes to install. They just want it to be simple. I see no reason why the interface to compiling cannot be as simple as the interface can be made for rpm or Winshield batch files or any other install program.
In fact they considerably broke compatability with most programs before that that tried to be "mac compatable". This is because almost all those programs used the "Alt" key as the equivalent of the Mac Apple key. Not the "Ctrl" key. A quick look at an Apple keyboard of that time and a PC keyboard will show you that Alt is the obvious choice. Take a look at the Win32 API and you will see they originally intended Alt to be used (it produces a different WM_SYSCHAR event, while ctrl produces a normal WM_CHAR event).
This is also why so many Linux programs vary on whether it is Alt+C or Ctrl+C that copies. They copied the Mac or PC at various times.
I tried to change my own NT programs to use Ctrl instead of Alt and the users complained that they were used to the Alt combinations, I was forced to put it back. This shows how little importance a "consistent GUI" really has! I have now settled on a scheme where Ctrl+letter modifies text fields, while Alt+letter is the shortcuts in all menus (Alt+C will copy large selectable objects, while Ctrl+C will copy text in the focused text field). This violates MicroSoft's "standards" but appears to be much more popular.
Anybody that claims MicroSoft is encouraging consistent GUI is full of shit. I really believe they did this to break compability with programs that were not written by them.
It might make sense to raise all the icons if any are clicked on. That way they are sort of a window as well. Another way to think of it is that the whole desktop is a transparent window that may be raised (then clicking anywhere raises them).
Personally I agree that icons are a bad idea. But one problem with the design is that people fail to consider all possibilities.
Why can't they just insert a "this may not work on your browser" message at the top of the page and then spew one of the versions anyway. Maybe it will work, and you have warned them that it might not so who cares if it does not, and this requires no more work than the current scheme.
If this were a problem they would have to require that somebody not read GPL code. They would also have a problem if the employee already has read some GPL code. It does not appear the companies are making such requirements, so this is still irrelevant to the argument: whether or not the company forces the employee to sign this agreement, it does not change how much GPL code that employee can look at and potentially steal from.
And seriously: programmers are hired from different companies all the time and they bring with them knowledge of how the older company's software works, and legally they are not supposed to use this. This has not caused very much trouble despite the fact that the source company probably has a lot more legal clout than the GPL would ever have.
This has nothing to do with that. This is to allow the employee to work on outside projects and put those under the GPL. It has absolutely no effect on what the employee can and can't do to the code they write as part of their employment.
Since it's all about information wanting to be free, maybe RMS should offer his courses free of charge.
Ha ha, you think you are so clever, don't you. But RMS does offer the course free of charge. He allows anybody to record them, transcribe them, etc and send that information to anybody they want.
I think he does charge if you want for some reason to hire him to actually speak the words. But the words are free.
Slashdot Mirror
The X resources are stored with the server, which is very useful for getting the interface correct when you can run remote applications. In addition they allow the resources to be different per application, something none of the theme systems seem to address.
However I very much disagree with the way Motif used it, where they turned it into a huge database that could not be programmed without intricate knowledge of the innards of the application (and often where the program was unusable unless several hundred correctly-set fields were in the database). I also disagree with their inane attempt to merge several (eventually dozens) of files by the application to get the database (ie the "appdefaults", searching for ".Xresources", etc) rather than leaving this to another program and only using the resources string from the server.
The X resources should be on the level of the Win32 preferences settings, very general like they were intended when X was designed, things like "text background color". Not the Motif scheme where the color of every single button can be set individually. This sounds powerful, but is actually totally useless to any real user and makes the database obscenely complex.
Basically Qt and GTK get it wrong by not reading their settings from the database, and Motif got it wrong by turning the database into a Windows-like "registry" with all the bugs needed.
PS: You can easily emulate the X defaults on Windows, just read them from a file! You should also read the Win32 preference settings, it should be trivial to make the toolkit #ifdef in some code for this at the same point it reads the X defaults. With the design specified above there should be no reason to use the Xt or Xrdb functions, just parse the string yourself.
The point is that the weight of importance of the applications is not equal. The importance is so unequal that you might as well ignore all those other 39,999 applications!
PS: I would also add Quicken to the necessary list. People seem to ignore this because it is not "evil MicroSoft" and it is believed it would be trivial to port it if they ever decided to.
Yea you can worry about those apps being sent to you by regulatory agencies, but for the vast majority of people, the only thing they are sent that does not work on Linux is MS Word documents and Excel spreadsheets.
It should not be exceptionally difficult to make old X programs work anyway, by making an Xlib replacement that translates the calls and throws away things that cannot be done on the new system. The only X programs that would not work would be window managers. This should be vastly easier than making WINE work. You could also make an "X server" that uses this library so remote X applications work.
There are about a dozen viable replacements (I like the look of DirectFB, but Atheos looks pretty good too though it may have the toolkit problem described below).
There are a few problems with the replacements, though. First is that they often throw out the client/server model and rely on shared memory. In my opinion this eliminates the one good thing about X, which is that programs from many sources can share the screen. I also think client/server can be far faster than shared memory, due to the triviality of making it multithreaded. The problem with X that causes these shared memory ideas is that X has far too many "synchronous" calls, where the call has a return value. The interface needs to be designed to by almost entirely asynchronous, so that thousands of calls can be batched together into a single context switch.
The other problem is too many of the replacements try to force a "toolkit" on the programmer. This is like trying to make a file system that requires you to use MySQL to do all possible manipulations of the files. It is too high level, complex and thus potentially buggy, and it forces you to use current-day designs and precludes any innovation.
Excellent description of the equivalence. If GPL is "viral" then their own code is "viral". This point needs to be hammered home, there are people here on slashdot that show amazing ignorance of this, you can imagine what people in the real world think!
You can write all the code you want and not put it under the GPL, and can sell it for whatever you want!
Oh, boo hoo, you can't take the source code with Linux and turn it into your own profit-making program. I'm just so sad for you. Hey, do you think you can take MicroSoft's code and turn it into a profit-making program without MicroSoft having something mean to say to you?
LGPL is more free than MicroSoft's libraries because besides the ability to use it in closed programs, you can also make derivative libraries (which must be open source, like GPL programs).
Now not everything is rosey:
1. The LGPL has some strange wording that makes many people think the libraries have to be shared. I personally don't think so, but this belief puts a lot of annoying requirements on the library, and requires "installation" and "dll hell" for programs that use them. Rather than question this we have modified the LGPL to specifically say that static linking is allowed.
2. RMS has a strange idea that putting libraries under the GPL will force people to make the programs under the GPL due to the "virii" nature. This is absurdly untrue, the result is that people don't use the library at all, and they then use a commercial library that runs only on platforms that are made by large Seattle companies whose name starts with M. Putting useful libraries under GPL licenses is seriously hurting the acceptance of Linux as it is stopping the creation of commercial programs that port to Linux. Fortunately most everybody else appears to disagree with RMS and use the LGPL or Berkely licenses for libraries.
I can't understand why anybody would consider any technique for naming information sources that does not cause open/close/seek to be able to manipulate those sources. Requiring this "vfs library" goes completely against the Unix design.
I would much rather see effort going into creating such easy to use programming interfaces, rather than these huge bloated libraries with interfaces that make MicroSoft's stuff look acceptable, and copies of MicroSofts rather lame ideas for GUI. The killer apps are going to come out of some teenager's basement, but only if the power in the system is accessible by mortals, and this is only going to happen if it is simple enough to be understood without years of study.
This may be true on newer NT systems (this was NT4.0). However the lack of symbolic links (which should be trivial to implement compared to hard ones) is still glaringly obvious.
Okay, the files should be of the form [name].[extension]. [name] is a user friendly name, ie something that a person of average intelligence may type, like "Helvetica". An example of a non-user-friendly name, which is not allowed under my design, is "adobe-helvetica-bold-normal-p".
[extension] is the user-unfriendly part and each font using service looks for a set of extensions it understands. Examples are "pfa", "ttf", and maybe "xfont.25.25" for an x bitmapped font that is designed for a pixel size of 25 vertically and 25 horizontally.
Somebody asked about designing it. Well here goes:
Fonts are stored in /usr/share/fonts and /usr/local/share/fonts. FreeType, GhostScript, X, and all other programs that load fonts are modified to look for all their files there.
The files are all of the form .. is a USER FRIENDLY name that can easily be typed and rememberd. The extension is used to distinguish various incompatable font formats, or different transformatons of image-based font formats. Systems that don't understand an extension ignore those files as though they are not there.
Fonts may also be stored in subdirectories, but in this case the "name" has slashes in it, so the services can just consider them normal file names.
Font files are found by a service taking the user-friendly name (X servers will have to extract a few fields from the ugly X name to get this) and tacking on each extension the service understands and checking if the file is there. There is no need to use readdir to get a specific named font. Services can assumme that once they see a font, that file will not be changed or disappear, although they may want to check the date stamp every now or then.
Services that need to search for fonts will have to recursively readdir the entire directory tree. They should be written so they don't do this on startup but instead delay it at least until the first font is requested. They should record the datestamp of the root directories and rerun the search if it has changed. Services are allowed to create their own cache files but they should create them in some other directory, as they may have read-only access to the font directories.
Multiple names for the same font (like "Ariel" or "helvetica" for "Helvetica") are done with symbolic links.
Yes it is quite likely that the first implementations will ignore each other's fonts. I expect they will gradually start to read each other, and that obsolete formats will disappear, and eventually there will be one file for each font.
You can make symbolic links, but only programs that use the cygwin libraries works with them, which makes them pretty close to useless.
PS: symbolic links would be much more useful (I'm sure there are many people who think hard links are a mistake in Unix design and symbolic links should be used everywhere), and could easily be implemented in NT (or any other system) without affecting the file system, as long as there is space for one bit that can be set on each file entry (to indicate that it is a symbolic link). The reason MicroSoft does not support them is obvious: it would instantly allow interoperability with Unix because you could eliminate the drive letters and make things like home directories appear in the "Unix" locations without breaking any Windows software. Actions like this, much more than "secret interfaces" (which are really the result of incompetent programmers who don't document what they are writing, than of some evil conspiracy) are a much clearer indication of how much MicroSoft wants to disallow interoperability. MSDOS had a simple symbolic link (the destination had to be a disk) called "assign", this was conspicuously deleted from newer versions of the system. From my own experience with writing portable software, the drive letters are a bigger hinderance to interoperation than anything having to do with GUI.
Again, please give an example of SOURCE CODE for a PRODUCT and stop trying to change the rules to weasel out of this!
I do think people saying things as stupid as you did hurt any attempt to have a reasonable attempt to argue against the GPL. I myself am having trouble with the GPL but we need logical arguments to suggest there may be alternatives. Spewing stuff about "the GPL is not free" is like calling people communists or nazis, or calling everybody at MicroSoft evil. It does not convince anybody and makes you look like a fool.
Can you give an example of a product (ie sold for money, or considered of significant added value when bundled with Windows) made by MicroSoft where they allow you to use the source code in your own product where you are not required to return some compensation to MicroSoft.
PS: in case you are wondering, I don't consider the GPL all that great. I have used the LGPL for my code, but I am changing it to specifically allow static-linked closed source executables, because I believe that the GPL's prevention of closed-source products is a detriment to it's use and adoption. However I don't think people should say obviously stupid things like "MicroSoft's software is more free" as it harms any kind of meaningful discussion.
Text-mode Microsoft word used Alt exclusively for all the menus. Control ran their own strange keybindings and I don't think it used Ctrl+C for copy (they used that Shift+Delete idea).
Certainly the first Windows programs (I worked with the tiled version of Windows, before 3.1) did not reserve Alt for shortcuts to bring down menus. There was no such concept. The underscores did not show up until Windows 93. You were certainly allowed to use Alt+letter in the menus (I did this in my Windows programs), I don't know if the underscores took precedence as I never used them.
I also have never seen an X program that used Ctrl to act like the Mac before about 1995, but plenty that used Alt. I would think if this was a MicroSoft standard for Windows93 there would have been at least one example.
The Emacs bindings do not conflict with reasonable use of Ctrl, IMHO. I prefer a combination of MS style ZXCV and Emacs bindings for all the other keys. The fact that there is no shortcut for start/end of line is pretty inexcusable, and making ^A select all text has caused me to lose untold amounts of work because I type it by accident all the time.
Now that is just being stupid. I would like you to point out a single example where MicroSoft allowed anybody to use their source code in a closed-source product without returning something to MicroSoft.
Too many ignorant people don't realize that code can be released under multiple licenses. Therefore, if I write some GPL code, I may be willing to sell it to you for a price for use in your closed-source product. You can also take the GPL code and use it in an open-source product. As far as I can tell this means you can do more with the GPL code than you can with any MicroSoft code.
And don't go saying the code examples in the MicroSoft manuals are free of any encumberances. So are the code examples provided with GCC! Boy can people be thick sometimes...
Ie when you double-click the "install this" it runs the compiler as necessary.
I don't think anybody cares how long it takes to install. They just want it to be simple. I see no reason why the interface to compiling cannot be as simple as the interface can be made for rpm or Winshield batch files or any other install program.
This is also why so many Linux programs vary on whether it is Alt+C or Ctrl+C that copies. They copied the Mac or PC at various times.
I tried to change my own NT programs to use Ctrl instead of Alt and the users complained that they were used to the Alt combinations, I was forced to put it back. This shows how little importance a "consistent GUI" really has! I have now settled on a scheme where Ctrl+letter modifies text fields, while Alt+letter is the shortcuts in all menus (Alt+C will copy large selectable objects, while Ctrl+C will copy text in the focused text field). This violates MicroSoft's "standards" but appears to be much more popular.
Anybody that claims MicroSoft is encouraging consistent GUI is full of shit. I really believe they did this to break compability with programs that were not written by them.
Personally I agree that icons are a bad idea. But one problem with the design is that people fail to consider all possibilities.
Why can't they just insert a "this may not work on your browser" message at the top of the page and then spew one of the versions anyway. Maybe it will work, and you have warned them that it might not so who cares if it does not, and this requires no more work than the current scheme.
I am pretty certain I saw this more than 2 years ago. Can anybody confirm?
If this were a problem they would have to require that somebody not read GPL code. They would also have a problem if the employee already has read some GPL code. It does not appear the companies are making such requirements, so this is still irrelevant to the argument: whether or not the company forces the employee to sign this agreement, it does not change how much GPL code that employee can look at and potentially steal from.
And seriously: programmers are hired from different companies all the time and they bring with them knowledge of how the older company's software works, and legally they are not supposed to use this. This has not caused very much trouble despite the fact that the source company probably has a lot more legal clout than the GPL would ever have.
Maybe you can still redeem one of the biggest sins ever done in Comp Sci...
This has nothing to do with that. This is to allow the employee to work on outside projects and put those under the GPL. It has absolutely no effect on what the employee can and can't do to the code they write as part of their employment.
Ha ha, you think you are so clever, don't you. But RMS does offer the course free of charge. He allows anybody to record them, transcribe them, etc and send that information to anybody they want.
I think he does charge if you want for some reason to hire him to actually speak the words. But the words are free.