MicroSoft has allowed Linux-only systems. Otherwise they would not exist and you can buy them. It is far more important that dual boot systems can now exist. If you assumme that Windows is required for some uses of a home computer, the disallowing of dual-boot effectively eliminated all competition.
I thought the problem was that MicroSoft did not allow dual boot machines. Either it had only Windows, or it did not have Windows at all. Because of their monopoly it is almost a requirement that a computer you buy have Windows on it, so disallowing dual-boot prevents any possible competition from an alternative.
The lack of dual-boot machines is often stated as why BeOS failed, and it probably prevented some other commercial enterprises such as the computer manufacturers making their own alternative OS. If dual-boot was allowed I think everybody would be playing games (and possibly doing video editing and multimedia) on alternative systems. Most likely the game console makers would be selling machines that are both Windows computers and game consoles.
MicroSoft has squashed competition so much that there is nothing left except Linux, so that people don't even have any idea of what types of things were killed by them. It was probably a lot more than Linux.
It would be nice if dual-booting is allowed, but it is probably sad that this will be of no use except to run Linux.
Actually I remember a lot of complaining here that the Linux client worked worse than the Windows one, so it sounds like they didn't care about anybody.
Good idea. Mostly people said that the result should include some code that requires running the entire test to calculate. But to test if that returned code is correct requires the same amount of time. Instead maybe it could calculate 5 or 10 (or more) independent codes, somehow designed so you calculate all of them as a side-effect of doing the real calculation, but where any one of them can be calculated in 1/5 or 1/10 (or less) of the total time. The checker can then just calculate a random one and is thus much faster than the client.
What the client several files? It sounds like the FFT DLL would be a seperate file. Why did they do this? If they want to obscure the code getting rid of symbols in a shared library would be a very good idea. Otherwise it is just like getting the source.
I am also suprised that you were able to figure out what the arguments to the DLL functions were. Ones I have seen take dozens of arguments, or large structures, and accidentally swapping x and y could result in it not working. Or did you decompile the DLL? Or did you really have the source code.
In any case SETI could easily prove your implementation worked by running the same block of data through both versions. Why they would not accept an improved Windows client is a mystery.
Although I agree that open source is the only way to come up with a truly cheat-proof system, there is a serious problem with using it here.
If you assumme altering the clients is difficult then you may be able to rely on slight differences between the real clients and cheating clients to send data that will only work in the real clients. This can be done without changing the clients.
However in a open-source solution it is far too easy for the cheaters to see what difference you are exploiting between the real and cheating clients, and modify the cheating client to emulate the difference. So any real fix will require all the clients to be replaced with new ones that do the new trick that makes the cheat impossible. Updating all the clients this way would require the entire system to be stopped.
The closed-source one will fail eventually when there is no way to distinguish a cheater from a real client. In that case it is just as hard to update things as the open-source one. However this may happen later.
It's good to see somebody who actually checks what people have done!
An event structure that is passed by reference may be a reasonable change to fltk, but it would break a huge amount of software already written. Also I have not really had the need to think about more than one event at a time, and the static locations greately assist checking the event without having to have an event argument added to every single call.
Where the idea fails is when events vary depending on what widget they are sent to. In fltk2.0 the x/y are being modified so they are relative to the corner of the widget, unfortunately for compatability this is done by changing the static locations back and forth. If it were not for compatability I would make a method on a widget that figures out and returns the x/y from the static global x/y. But this would still allow the x/y to be in static locations.
Well the virtual consoles were written when the 2-button MicroSoft mouse was popular on PC's. I just tried it and it looks like both the middle and right mouse buttons paste. In any case I think for the average user "any program" means "any X program".
There is no X preference for what mouse does paste, so there is no "setup" either (unless you are counting xmodmap, but if you mess with that you will change a lot more than just what key does paste). The programs either get it right or get it wrong. As far as I can tell they all agree.
There are problems and the problems are that some API's are not designed well. But this has nothing to do with "comprehensive API" or whatever you are blathering about. Rest assurred that Windows uses a different call for cut/paste than it does to read files, just like Linux.
X is "integrated" in that it actually uses communication calls that exist in the system and are used by other parts of the system. This is why it works remotely. In this area Linux is vastly superior to Windows for "comprehensive API", in Windows there is NOTHING below the graphics interface that is reusable by anything other than graphics. The fact that X has a horrible interface is certainly true but irrelevant to "comprehensive".
Also I don't think right-mouse pastes in ANY program. Middle mouse does, and it works in every X program I have ever seen. The inconsistencies are in what Ctrl+V does, not in what middle-mouse does. The fact that you did not know this indicates that you know little or nothing about Linux.
"b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,"
Please explain how somebody gets ahold of this written offer without violating security regulations of the DOD or whoever wrote the "secret" program.
It is well established that GPL code can be used inside an organization for whatever purpose that organization wants, and there is absolutely no requirement that anybody inside or outside the organization get access to the source code.
The purpose of the GPL is so that anybody who owns a program can modify it for their own uses or interoperate with it (they can of course "modify" it to free copies thus allowing others to "own" it). It is not in any way intentded to grant anything to people who don't have the program. The "third party" thing has been explained a million times over that the "third party" is supposed to have a copy of the program.
I think the request was for middle-click on form buttons to bring up a new tab. I have always wanted this (back in Mozilla where I wanted it to just open a new window). I would also like it if this was done for javascript "buttons". It would also be nice if middle-mouse click on something that changes another frame would instead put the new frame contents in a new tab. Basically, as much as possible, middle click should mean "new tab".
Conversely it would be nice if left-click *never* brought up a new tab or window, even if the program tried to do it with javascript or frame tricks. Instead it should replace the current window all the time.
No, only people who have the program are allowed to request the source code. If somebody has a top-secret government program then they have probably broken the law somehow.
If it is a government secret you can then arrest that requestor (and whoever gave them the program) for violating whatever security arrangement they were made to sign.
Companies can write Top Secret code that is distributed to other companies and even sold.
You are correct that such a program could not include any GPL code.
If you link it in to your code, you are required to release the source code. Just because people may not know it exists does not mean you can hold the source proprietary.
As has been pointed out about a million times here, the GPL only requires you to release the source code to the people you distribute to. If somebody does not know a program exists then they obviously have not been distributed to, so they have no rights to the source code.
This ignores the fact that you cannot link a GPL library into your proprietary code. For a company that writes top secret material, this is somewhat concerning that they would ignore this.
Yes you can use GPL in your proprietary code. You just are not allowed to distribute it to outside parties. If you are writing something top-secret where the secret would be revealed by examination of the source code, you would be pretty foolish to distribute the binary, too!
Somebody there was aware that there was a bunch of people who argue about the differences between "Free" and "Open" and which one is better, while for all practical purposes they are exactly the same. Combining the acronym was a good way to not take sides in the argument (I suspect the authors had no opinion either). I also think a word starting with a consonant is easier to pronounce and put into sentences.
Actually the results of PDF->ASCII are about as accurate as the results of the many.DOC->ASCII converters available. Both lose much of the formatting information and can scramble the order of the text.
It is probably possible to "edit" the PDF so it actually looks the same but has some of the words changed, but if the new wording is a different length it is going to require some work and probably hand-editing. I would think that a Linux user would have better luck modifying a.DOC in OpenOffice or something. Of course any real evil document-modifier is going to have access to a Windows machine with Word, and if Linux was useful for some documents they would have a Linux machine too.
Actually there is nothing stopping the Carbon emulation layer from working on x86. It just needs to be compiled and the programs using it recompiled. I think you are thinking about the OS9 *emulation* which actually runs programs that are compiled for the PPC, that probably won't be ported. But all the sample programs you list are actually compiled on OS/X.
Most people think that if Apple made an 86 version, they would also make their own hardware. So I don't see how that would be different to MicroSoft than the current situation. Then again, it might be easy to get a Wine-like emulator on the system, so maybe MicroSoft would be worried about it.
Umm, why not use Java 1.4 and Swing? That's about as crossplatform as it gets. Wx would be ok too
It does not matter how well those work, for any real application development "native widgets" does not work, no matter how much you wish it did. The differences are just too great. Simple things like order (system a needs A before you can send it B, while system b needs B before A) can make it impossible to port your code without the differences percolating directly to the highest level. How else do you explain that virtually all Open Source development uses toolkits (Qt, GTK, FLTK, Mozilla, Fox, Tk,...) that draw things at a low level and bypass any native widgets.
In any case, GNUStep, if it works, would be a very good idea. I don't have a good explanation as to why it does not seem to be succeeding, I know Gnome was looking for a toolkit at one time and they don't seem to have considerd using it. It may also be that it was too hard to make Windows-like programs using GNUStep.
Possibly the popularity of OS/X will help. GNUStep should make their #1 priority to clone Cocoa as closely as possible in such areas as widget sizes and shapes so that portable programs will work. If they do not do this then it will be just like wx where it is not much use for portable programs except for small demos.
Apple does not have to work on "installation" so I doubt the result will be that easy to install. On the variety of PC hardware I doubt they can do much better than the best Linux or Windows installers.
In the real world, Windows is infinitely easier to "install" because for most people it is on the machine when they buy it. It is not physically possible to make installation of any operating system easier than that. Apple has this same "easy installation" for their small segment of the market.
Most people here think that if Apple makes an 86 OS/X they will also make their own boxes to run it. You will not be able to run it on Windows pc's.
You have the explanation of the window raising correct. A simpler way is: there are exactly TWO ways of raising the window: *clicks* in the window border and any dead space that does not do anything else (such as gaps between buttons), and the program saying "raise this window". (in my ideal system at the low level in fact there is *ONLY* the program giving the "raise this window" command, but the toolkits would be written to give the impression to the user that the system raises windows when you click on dead area).
The problem with clicking raising windows is that if you have two displays that are too big to both fit on the screen, you cannot work on both of them by overlapping them. Clicking in the lower one would raise it and obscure the upper one. This is not wanted because there is a good chance it will obscure information the user wants from the former top window (there is ZERO chance it will reveal information from the former bottom window because if the user needed that information they would have to raise the window to look at it before clicking on that window). The result is that people have been forced to "tile" the windows, resizing them and designing displays that are able to be resized (including changing the aspect ratio), when in fact people are much better at handling objects that act like real physical things where portions can be obscured, but the objects themselves do not change shape.
This is extremely difficult to explain, there is a huge number of people (including me at one time) that don't see any reason to not raise windows when they are clicked on. However if you have worked with software designed for such systems (such as much 3D software used in visual effects) you would find out just how painful it is to use "tiled" systems. Imagine a program that wants to display a 1024x600 image and also a 1024x1024 graphical control at the same time, where the user often needs to click on both of them rapidly and very much wants to see what the results are in one of them based on changes to the other. This CANNOT be done in tiled systems.
Even if you disagree with whether this is a good GUI idea or not, the truth is that in any system where the program has a "raise this window" call, there is absolutely no reason for the system to raise windows. That is because the program can do this call on the clicks and you get exactly the same behavior as you are used to, but now programs are at least able to experiment with the behavior I want. I don't think there is any possible argument against changing systems to work this way because current behavior is emulated trivially.
"sheets" are much more similar to "modal child windows" that block interaction with the parent window. Since these are up for a very short time they usually have no time to get seperated from the parent or for the user to rearrange the windows, the bugs in the window managers (or designs like the Mac where you cannot seperate them) are not too painful.
What I was talking about is "child windows" that stay up but still allow you to interact with the parent. In a properly designed system where all window-raising is left up to the program these are useless, but I can use them *somewhat* to solve the overlapping window problem, since they prevent the "parent" from raising above the child (in my example the image viewer is a child of the graphical control). The huge problem is that the program has to choose the order, and cannot change it (at least not with kludges that make the windows blink as they are destroyed and recreated), and the user cannot decide what order they should be in. The other problem is what I was complaining about: raising a child window raises it's parent (and all the other child windows of that parent). This makes overlapping windows useless even on systems that can be instructed to not raise on click, because you still cannot do some useful stuff (unobscure the child) without raising a window you don't want raised.
I guess the OS/X equivalent are those slide-out trays, though they certainly don't solve my problem because you can only have one of these and the size is limited to the height of the parent window.
I have used OS/X and I can say I am extremely pleased that they got rid of the "application windows stick together" behavior, like you mentioned. It is a tiny, tiny, tiny baby step in the right direction!
Even if you think (as the Netscape 6.0 engineers clearly do) that Alt+Left is not a good shortcut key for "Back", there are literally millions of people out there who will try to use Alt+Left to go back, and if you refuse to do it on some general religious principle that Bill Gates is the evil smurf arch-nemesis Gargamel...
Actually Alt+Left was invented by Netscape and was used by their earliest versions. So if they changed it they are being even more stupid as they are not copying themselves, not to mention MicroSoft. I don't have it to test (I use Konquerer which uses Alt+Left for back) but are you sure your window manager is not eating the keystroke?
Maybe because the writer wants to sell the code to proprietary software developers?
No, that would not fit into your "the GPL is a Communist conspiracy" theory. In fact the GPL is put on code for extremely selfish reasons that would make Ayn Rand proud.
Slashdot Mirror
MicroSoft has allowed Linux-only systems. Otherwise they would not exist and you can buy them. It is far more important that dual boot systems can now exist. If you assumme that Windows is required for some uses of a home computer, the disallowing of dual-boot effectively eliminated all competition.
The lack of dual-boot machines is often stated as why BeOS failed, and it probably prevented some other commercial enterprises such as the computer manufacturers making their own alternative OS. If dual-boot was allowed I think everybody would be playing games (and possibly doing video editing and multimedia) on alternative systems. Most likely the game console makers would be selling machines that are both Windows computers and game consoles.
MicroSoft has squashed competition so much that there is nothing left except Linux, so that people don't even have any idea of what types of things were killed by them. It was probably a lot more than Linux.
It would be nice if dual-booting is allowed, but it is probably sad that this will be of no use except to run Linux.
Actually I remember a lot of complaining here that the Linux client worked worse than the Windows one, so it sounds like they didn't care about anybody.
Good idea. Mostly people said that the result should include some code that requires running the entire test to calculate. But to test if that returned code is correct requires the same amount of time. Instead maybe it could calculate 5 or 10 (or more) independent codes, somehow designed so you calculate all of them as a side-effect of doing the real calculation, but where any one of them can be calculated in 1/5 or 1/10 (or less) of the total time. The checker can then just calculate a random one and is thus much faster than the client.
I am also suprised that you were able to figure out what the arguments to the DLL functions were. Ones I have seen take dozens of arguments, or large structures, and accidentally swapping x and y could result in it not working. Or did you decompile the DLL? Or did you really have the source code.
In any case SETI could easily prove your implementation worked by running the same block of data through both versions. Why they would not accept an improved Windows client is a mystery.
If you assumme altering the clients is difficult then you may be able to rely on slight differences between the real clients and cheating clients to send data that will only work in the real clients. This can be done without changing the clients.
However in a open-source solution it is far too easy for the cheaters to see what difference you are exploiting between the real and cheating clients, and modify the cheating client to emulate the difference. So any real fix will require all the clients to be replaced with new ones that do the new trick that makes the cheat impossible. Updating all the clients this way would require the entire system to be stopped.
The closed-source one will fail eventually when there is no way to distinguish a cheater from a real client. In that case it is just as hard to update things as the open-source one. However this may happen later.
An event structure that is passed by reference may be a reasonable change to fltk, but it would break a huge amount of software already written. Also I have not really had the need to think about more than one event at a time, and the static locations greately assist checking the event without having to have an event argument added to every single call.
Where the idea fails is when events vary depending on what widget they are sent to. In fltk2.0 the x/y are being modified so they are relative to the corner of the widget, unfortunately for compatability this is done by changing the static locations back and forth. If it were not for compatability I would make a method on a widget that figures out and returns the x/y from the static global x/y. But this would still allow the x/y to be in static locations.
It's exactly the same.
There is no X preference for what mouse does paste, so there is no "setup" either (unless you are counting xmodmap, but if you mess with that you will change a lot more than just what key does paste). The programs either get it right or get it wrong. As far as I can tell they all agree.
There are problems and the problems are that some API's are not designed well. But this has nothing to do with "comprehensive API" or whatever you are blathering about. Rest assurred that Windows uses a different call for cut/paste than it does to read files, just like Linux.
X is "integrated" in that it actually uses communication calls that exist in the system and are used by other parts of the system. This is why it works remotely. In this area Linux is vastly superior to Windows for "comprehensive API", in Windows there is NOTHING below the graphics interface that is reusable by anything other than graphics. The fact that X has a horrible interface is certainly true but irrelevant to "comprehensive".
Also I don't think right-mouse pastes in ANY program. Middle mouse does, and it works in every X program I have ever seen. The inconsistencies are in what Ctrl+V does, not in what middle-mouse does. The fact that you did not know this indicates that you know little or nothing about Linux.
"b) Accompany it with a written offer, valid for at least three years, to
give any third party, for a charge no more than your cost of physically
performing source distribution, a complete machine-readable copy of the
corresponding source code, to be distributed under the terms of
Sections 1 and 2 above on a medium customarily used for software
interchange; or,"
Please explain how somebody gets ahold of this written offer without violating security regulations of the DOD or whoever wrote the "secret" program.
It is well established that GPL code can be used inside an organization for whatever purpose that organization wants, and there is absolutely no requirement that anybody inside or outside the organization get access to the source code.
The purpose of the GPL is so that anybody who owns a program can modify it for their own uses or interoperate with it (they can of course "modify" it to free copies thus allowing others to "own" it). It is not in any way intentded to grant anything to people who don't have the program. The "third party" thing has been explained a million times over that the "third party" is supposed to have a copy of the program.
Conversely it would be nice if left-click *never* brought up a new tab or window, even if the program tried to do it with javascript or frame tricks. Instead it should replace the current window all the time.
No, only people who have the program are allowed to request the source code. If somebody has a top-secret government program then they have probably broken the law somehow.
If it is a government secret you can then arrest that requestor (and whoever gave them the program) for violating whatever security arrangement they were made to sign.
You are correct that such a program could not include any GPL code.
If you link it in to your code, you are required to release the source code. Just because people may not know it exists does not mean you can hold the source proprietary.
As has been pointed out about a million times here, the GPL only requires you to release the source code to the people you distribute to. If somebody does not know a program exists then they obviously have not been distributed to, so they have no rights to the source code.
Yes you can use GPL in your proprietary code. You just are not allowed to distribute it to outside parties. If you are writing something top-secret where the secret would be revealed by examination of the source code, you would be pretty foolish to distribute the binary, too!
Somebody there was aware that there was a bunch of people who argue about the differences between "Free" and "Open" and which one is better, while for all practical purposes they are exactly the same. Combining the acronym was a good way to not take sides in the argument (I suspect the authors had no opinion either). I also think a word starting with a consonant is easier to pronounce and put into sentences.
It is probably possible to "edit" the PDF so it actually looks the same but has some of the words changed, but if the new wording is a different length it is going to require some work and probably hand-editing. I would think that a Linux user would have better luck modifying a .DOC in OpenOffice or something. Of course any real evil document-modifier is going to have access to a Windows machine with Word, and if Linux was useful for some documents they would have a Linux machine too.
Most people think that if Apple made an 86 version, they would also make their own hardware. So I don't see how that would be different to MicroSoft than the current situation. Then again, it might be easy to get a Wine-like emulator on the system, so maybe MicroSoft would be worried about it.
You are mostly correct except for this:
Umm, why not use Java 1.4 and Swing? That's about as crossplatform as it gets. Wx would be ok too
It does not matter how well those work, for any real application development "native widgets" does not work, no matter how much you wish it did. The differences are just too great. Simple things like order (system a needs A before you can send it B, while system b needs B before A) can make it impossible to port your code without the differences percolating directly to the highest level. How else do you explain that virtually all Open Source development uses toolkits (Qt, GTK, FLTK, Mozilla, Fox, Tk, ...) that draw things at a low level and bypass any native widgets.
In any case, GNUStep, if it works, would be a very good idea. I don't have a good explanation as to why it does not seem to be succeeding, I know Gnome was looking for a toolkit at one time and they don't seem to have considerd using it. It may also be that it was too hard to make Windows-like programs using GNUStep.
Possibly the popularity of OS/X will help. GNUStep should make their #1 priority to clone Cocoa as closely as possible in such areas as widget sizes and shapes so that portable programs will work. If they do not do this then it will be just like wx where it is not much use for portable programs except for small demos.
In the real world, Windows is infinitely easier to "install" because for most people it is on the machine when they buy it. It is not physically possible to make installation of any operating system easier than that. Apple has this same "easy installation" for their small segment of the market.
Most people here think that if Apple makes an 86 OS/X they will also make their own boxes to run it. You will not be able to run it on Windows pc's.
You have the explanation of the window raising correct. A simpler way is: there are exactly TWO ways of raising the window: *clicks* in the window border and any dead space that does not do anything else (such as gaps between buttons), and the program saying "raise this window". (in my ideal system at the low level in fact there is *ONLY* the program giving the "raise this window" command, but the toolkits would be written to give the impression to the user that the system raises windows when you click on dead area).
The problem with clicking raising windows is that if you have two displays that are too big to both fit on the screen, you cannot work on both of them by overlapping them. Clicking in the lower one would raise it and obscure the upper one. This is not wanted because there is a good chance it will obscure information the user wants from the former top window (there is ZERO chance it will reveal information from the former bottom window because if the user needed that information they would have to raise the window to look at it before clicking on that window). The result is that people have been forced to "tile" the windows, resizing them and designing displays that are able to be resized (including changing the aspect ratio), when in fact people are much better at handling objects that act like real physical things where portions can be obscured, but the objects themselves do not change shape.
This is extremely difficult to explain, there is a huge number of people (including me at one time) that don't see any reason to not raise windows when they are clicked on. However if you have worked with software designed for such systems (such as much 3D software used in visual effects) you would find out just how painful it is to use "tiled" systems. Imagine a program that wants to display a 1024x600 image and also a 1024x1024 graphical control at the same time, where the user often needs to click on both of them rapidly and very much wants to see what the results are in one of them based on changes to the other. This CANNOT be done in tiled systems.
Even if you disagree with whether this is a good GUI idea or not, the truth is that in any system where the program has a "raise this window" call, there is absolutely no reason for the system to raise windows. That is because the program can do this call on the clicks and you get exactly the same behavior as you are used to, but now programs are at least able to experiment with the behavior I want. I don't think there is any possible argument against changing systems to work this way because current behavior is emulated trivially.
"sheets" are much more similar to "modal child windows" that block interaction with the parent window. Since these are up for a very short time they usually have no time to get seperated from the parent or for the user to rearrange the windows, the bugs in the window managers (or designs like the Mac where you cannot seperate them) are not too painful.
What I was talking about is "child windows" that stay up but still allow you to interact with the parent. In a properly designed system where all window-raising is left up to the program these are useless, but I can use them *somewhat* to solve the overlapping window problem, since they prevent the "parent" from raising above the child (in my example the image viewer is a child of the graphical control). The huge problem is that the program has to choose the order, and cannot change it (at least not with kludges that make the windows blink as they are destroyed and recreated), and the user cannot decide what order they should be in. The other problem is what I was complaining about: raising a child window raises it's parent (and all the other child windows of that parent). This makes overlapping windows useless even on systems that can be instructed to not raise on click, because you still cannot do some useful stuff (unobscure the child) without raising a window you don't want raised.
I guess the OS/X equivalent are those slide-out trays, though they certainly don't solve my problem because you can only have one of these and the size is limited to the height of the parent window.
I have used OS/X and I can say I am extremely pleased that they got rid of the "application windows stick together" behavior, like you mentioned. It is a tiny, tiny, tiny baby step in the right direction!
"point at drivers"???? I'm sure Grandma can figure that out!
Actually Alt+Left was invented by Netscape and was used by their earliest versions. So if they changed it they are being even more stupid as they are not copying themselves, not to mention MicroSoft. I don't have it to test (I use Konquerer which uses Alt+Left for back) but are you sure your window manager is not eating the keystroke?
No, that would not fit into your "the GPL is a Communist conspiracy" theory. In fact the GPL is put on code for extremely selfish reasons that would make Ayn Rand proud.