Wrong. In official Microsoft documentation before Windows 98, it was Ctrl+Insert for copy, Shift+Insert for Paste, and Shift+Delete for cut. Around Windows 3.1 many programs ignored this and copied the Macintosh and used Alt+C,X,V. In Windows 95 Microsoft finally gave up and made it Ctrl+C,X,V (they wanted Ctrl for menu shortcuts to avoid conflicts with foreign keyboards that used Alt as an extra shift key).
The three icons were added in Windows 95. In earlier versions closing the window was done by double-clicking the top-left button.
Now go hang your head in shame for such blatant mis-information.
In reality, copyright violations and stolen code are far more likely in closed-source. This is for the simple and obvious reason that it is a lot easier to hide the fact that you did it because far fewer people see it. I'm not talking about a company willingly stealing code, I am talking about the individual developers and contractors working for that company who are quite willing to steal and cheat to get their job done and hope the boss does not notice. OSS contributors cannot do this because they know the code will be looked at by thousands of people, at least half of who do not have an interest in using the code and may actively want to find a reason to reject your code (ie because they have their own competing contribution). Compare this to a company where at most a few dozen people look at the contributed code and all of them are interested in having the project done.
Okay, I tried it again. I can set "Inactive inner window" to "Activate and pass click". But this does not work, it still raises the window. Since I'm also using point-to-type I suspect it thinks the window is not "inactive", but there is no option for "active inner window" for me to change. I'm sorry, but it appears they do not test this, so it does not work and is useless.
Besides I stand by my original assertion that if they just defaulted to not doing anything, it would be trivial for programs that want the current behavior to replicate it by raising their own windows. The fact is my software cannot assumme it can avoid this greatly limits my choices. Our software really wants to display several image viewers of 1024 pixels wide or larger, with controls the user can manipulate in them, usually they want to move the controls in one small area while referring to a different image. On Irix using 4DWM this was trivial and quite intuitive to extreme novice users, they could grab the window titles and slide the windows so the part they are interested in was visible, and then manipulate them all they want, and never lose sight of the information they wanted to see.
On Windows and Linux I am forced to zoom way out so the windows can be made small enough so that they don't overlap, and use non-integer zoom so they are not so tiny as to be useless, this results in very ugly images, despite the fact that we are using very high-quality filtering, compared to the very smooth and instantaenouse 1:1 or 1:2 scaling that we could do on the "old fashined" Irix system, and details like dust and bad edge pixels are lost, and the user can easily be misled as to whether they have lined up images with each other, resulting in expense and wasted time when these mistakes are not detected until filmout. The screen space used by the title bar is useless, as the user cannot move the window in any useful way, instead they have to use the panning controls in the program to move the image inside the window. Any attempt to move or change the size of the window requires fiddling with the size of the other windows so they don't overlap, a tedious waste of time. Most software is forced to go to a tiled layout to solve this tedious resizing, but I don't want to do that because it requires a parent window and large empty useless areas in it, at least with sepearte windows they can put their IM client or other things in the holes and use them.
They may think they are offering choice, but mindless copying of Windows means they don't test alternatives sufficently that you can use them. In KDE, turning off the click-to-raise also turns off the ability to raise windows by clicking on the title bar, which is not very useful or user friendly. Also all CDE-style window managers (and Windows) have a bug where if you raise a "child" window, it also raises it's parent to immediately below the child. This is just as bad as raising a window when you click inside it, and I have not seen a single modern window manager that does not have this bug. (my window manager flwm does not have this bug, so at least it proves that it can be avoided).
More importantly, as long as programs cannot assumme they can avoid click-to-top, they have to work around it. This means making child windows even when they are not modal, and using single-window/dockable/tiled/MDI type interfaces.
The biggest annoyance is that if they would just turn it off, it is trivial for programs that want click-to-top to turn it back on (all they have to do is raise themselves in response to a click). The opposite is not true, I have no way to avoid raise-to-top (except elaborate kludges with messing with the TRANSIENT_FOR property which can fool some window managers). If they would turn this off permanently they would really be offering "choice".
Um, MDI literally means MULTIPLE DOCUMENT INTERFACE. Notice the word MULTIPLE. This means that several documents are in windows that are framed by another window. MDI was designed for exactly one purpose: to avoid swapping in other programs by avoiding the need to expose their windows when the user moved the window they were working on. This was necessary when Windows 3.1 came out (before that Microsoft tried to tile the entire window system, similar to the old Andrew window system and Lisp machines). This is absolutely and utterly obsolete nowadays.
I suspect you are actually talking about framing different windows that make up the interface to one document, such as various toolbars and control panels, so that they all move together. On more modern programs they are often "tiled" to be adjacent to each other and you cannot overlap them.
Please don't call that "MDI", as the term in wrong. Perhaps "single window interface" is more accurate, especially with the newer tiled ones.
Personally I don't think single window interface is necessary, except for an annoying bug that is in Windows and has been copied on all the modern Linux desktops: the fact that clicking inside windows raises them to the top. This makes use of overlapping windows almost impossible, and has forced everybody to go to a tiled arrangement, or framing a hierarchy of child windows, so that the raised windows do not obscure important things.
It would also be helpful if windows could be identified as belonging together in some way other than the child stacking order, so that iconizing the main document could hide them all, and they only take one entry in the taskbar. This is the other reason for the single window interface (in programs like Photoshop which still allow overlapping inner windows), and a lot of the reason for multiple desktops in Linux.
The Windows POSIX was purposely designed to not interoperate with other programs in order to discourage it's use. Microsoft wrote it only to fulfill government purchasing requirements.
Both this thing and cygwin read and write the same files with the same names as Windows-native programs, and do many other things that would seem obvious but the POSIX system does not do.
More accurately ctrl.alt.+/- just change how the screen memory is mapped to the screen, so you see a subrectangle. As far as I know, there is no way for a program to even find out that it is happening.
I'm unsure what the point is today with LCD screens, however. Running at any resolution other than the matching one looks like crap, so this idea is entirely obsolete.
I think a lot of this "change resolution requirement" is due to the fact that Windows did it, so people all said "it's intuititive and useful". I'll bet if Windows had fixed resolution and changing it was some feature of Linux, we'd have lots of people complaining about this "useless frill that just confuses users, why can't we leave the windows where they were?", while Linux zealots would be claiming that resoultion-changes is proof positive that Linux is the best thing in the world!
In 1985 just before the Macintosh came out, the standard on PC's was to use the numbered function keys for cut & paste (and for every other action). About the only real "standard" was that Microsoft Word (the DOS version) used Shift+Delete, Ctrl+Insert and Shift+Insert, and due to the fortunate fact that few other programs had assigned anything to those keys, other software was easily able to copy this, so there was a bit of uniformity. Except for Emacs clones, I never saw any software use Ctrl+letters for anything, typing them either inserted smily faces or inserted ^X notation.
The Macintosh definately standardized on the Apple+X,+C, and +V for cut, copy, paste. Also on Apple+Z for Undo. The X and C sort of make sense from a menemoic point of view, but it is pretty obvious these were selected for their positions on the Querty keyboard. I have no idea if Apple copied this layout from Xerox or anywhere else (like Apple II applications?)
After that you started see Mac-like programs on PC's and on Unix workstations such as Sun. I never saw one from that age that did not use Alt+X,Alt+C, and Alt+V for these actions. Compare a Mac and a PC keyboard from this era and it should be pretty obvious why Alt was chosen: the keys are in the same place. This is the source of the large number of Linux programs that "use Alt instead of Ctrl and are therefore inconsistent". The first versions of Windows (ie before 3) used Alt as the standard key for menu shortcuts, although Microsoft denies this, but I worked with those versions so I know. At that time Microsoft was still pushing the Shift+Insert idea as the "Windows standard" and these were displayed in the menus for the cut/copy/paste items.
For some reason (my best guess is due to conflicts with foreign keyboards which used the Alt key for shifting some keys to get foreign letters), in Windows 3.1 Microsoft changed the standard menu item shortcut binding from Alt to Ctrl. They also appeared to give up their attempt to be different than the Mac and made menu items for cut/copy/paste with Ctrl+x, ctrl+c, and ctrl+v shortcuts, hiding the shift+insert stuff (though they still work).
By "everything has to be rasterized" he is probably talking about the fact that you cannot draw antialiased anything on current X except by drawing the resulting composite into a local bitmap and sending it. I agree with the original poster that this is a problem with the absurdly primitive X rendering model. But an interface whereby which anything describable by even PostScript can be rendered by the server does not exist on any platform, except perhaps OS/X.
A more accurate criticism of X is that they refused to add even the simplest "draw this image with alpha". This would get rid of about 90% of the reason GTK and other toolkits have to draw all their graphics in local memory and send it. Anti-aliased lines and shapes would be nice but Microsoft doesn't seem to be in any rush to do them either...
KMail has always worked with SMTP for me, without any changes. I also find it hard to believe that anybody would claim rebooting would fix it if it was broken, so I think you are making this up.
I am annoyed that the command-line "mail" does not work, however, and I have to use KMail to send everything. How come the fancy GUI tools work while the basic building blocks don't? This is actually the fundemental problem software engineers have with Windows, and it seems Linux is duplicating those problems as fast as it can.
What the hell are you talking about? Did you even try typing Ctrl+X and Ctrl+V? It works in every single modern program out there, IDENTICALLY to Windows!
The middle-mouse click is drag and drop, not cut & paste. Pretend it doesn't exist and maybe you will see the light. A Windows-only user would probably have an easier time than you are having...
Your post is strange. The complaint about Linux is that stuff *OTHER* than text does not work. The numbers in your spreadsheet will cut and paste just fine. Try it. Cutting & pasting images does not work, and this is entirely on the brain-dead "pure" design the original ICCCM people did back when Unix design was being dictated by the OSF and other buracracies. (basically the problem is that although the design is almost identical to Windows, the ICCCM said "here is where you put the number identifying the type of data, but we won't say what the numbers should be because that is not our job", while at the same time Microsoft said "hey if you put a 14 in there it means a.BMP file" (note the number is not correct, but that is the idea).
Also, I challenge you to find any modern program that does not use Ctrl+X and Ctrl+V for cut and paste (yes the middle-mouse stuff works as well, but that does not mean the Windows shortcuts don't work).
If you say "Emacs" or anything like that, I would like to point out that cut & paste don't work in Emacs on Windows either. I mean MODERN programs, ie written after Windows 98 came out, which is when all the programs you are comparing to on Windows date from.
There are *TWO* different things that are commonly called "alphablending" and they are suprisingly unrelated.
One of them is just the ability to draw a thing that is "partially transparent" atop another thing. You can't "take them apart" later, the only thing stored is the resulting composite. Until 2 years ago this is 100% of what people were thinking of when they said "alpha" and IMHO it is also vitally more important than the other problem, described below. This is addressed in the current XFree86 with the XRender extension. The main use you may have seen of this is for anti-aliased text, however it can also be used to draw transparent images or to draw antialiased filled shapes and curves. The XRender API is way too hard to use, so a project called Cairo is writing a new graphics library atop it to address this.
The other, UNRELATED, thing is basically "back buffer with alpha and hardware compositing to the screen for each window". This is used to make "transparent windows" and shadows. It could also be used in a much more useful way to produce shaped windows with anti-aliased edges, though I have not seen this done even on the Mac. This does not exist in available XFree86 implementations, though it is in the development versions from Freedesktop.org. It is not as far along. Unfortunatly this rather unimportant piece of eye candy is now what everybody talks about when saying "alphablending" and especially on the Mac and Windows is being used and developed much more extensively than the much more useful antialiased drawing of images.
My ISP runs SpamAssassin and markes the spam in the subject lines. I think a good idea would be if a user approaches their storage limit, that the ISP then deletes all the SpamAssassin-marked mail. This is certainly better than deleting all the *new* mail, which seems to be the solution my ISP uses. It could delete everything higher than 5, then 4, then 3, etc, until the amount of email falls below the limit.
It would also help if the ISP had an option on the web page that said "throw away anything Spam Assassin thinks is spam". A user could turn it on if they decided SpamAssassin was doing a good job. I put a cron job in my ISP to do this (they provide a Unix shell) but I doubt that would ever be considered user-friendly.
The GPL does not restrict any rights that you have naturally under copyright law. You can "copy for fair use" the GPL source code all you want, put it on every machine you own, print it out, etc. The reason you cannot use it in a closed-source program and then sell or distribute the program is that you are violating copyright, not the GPL. The reason you can distribute the program with source code that is also GPL covered, is that the GPL explicitly says that if you follow those rules you are allowed to violate the copyright.
However, a Sun spokesperson said Green actually tendered his resignation "long before last week. It was coincidental timing, not related timing."
You mean to say that there was no indication to a top internal person that the decision to accept a 2B payoff was being considered, until exactly when it happened? Almost certainly he agreed to wait until the decision was announced before he quit. The fact that he decided "long before" does not mean it was unrelated...
Well you can also add plugins directly to the installation. But some may consider 3rd party plugins as not being part of the application and actually something else, so they should not be there. I mean you could consider every single program on Linux to be a "plugin for Linux" and thus they should all be in the one "Linux directory".
I feel installations that look in multiple places are ok as long as there is no requirement that those multiple places exist. The user can delete their ~/.app directory and the program still works, they just lose their plugins.
(note also that when I say ~/.app, I mean ~/.<name_of_app>)
Hard as it is to believe, it is even what techophiles believe to be the correct procedure. Only long exposure to Windows or Unix brainwashes people into thinking anything else.
It should be possible to use a hash to find identical copy-on-write pages loaded by the system and share them. This should allow non-shared libraries to become "shared" in memory, and would probably reduce memory usage. There may be startup-time issues, though: no matter how fast the hash is (even precomputed and on-disk), if there is a "hit" it has to compare the full 4K to make sure, so the better the sharing works, the slower programs load...
The problem with plugins is that they require the functions they call to be in a shared library (actually not a problem on Linux if you link with -shared, but we had to support Windows too, so we had to solve this).
In our software *everything* in in a single directory. What is there is:
1. A tiny "exec" program named after our app. This program figures out what directory it is in (from/proc/self/exe). It modifies the LD_LIBRARY_PATH to add this directory, and then execs the real program from the directory. This step is not needed on Windows, where the program's directory is always added to the library search path.
2. The real program
3. A shared library containing everything our plugins need.
4. A subdirectory containing all the plugins we provide with the program.
5. An "init" file that is text-editable. But by default it looks in ~/.app/ for the plugins as well as the plugins subdirectory. It will also source identical files in the ~/.app directory. So if you have your own plugins, you can add them by putting them in your home directory, by modifying the init in your home to point where they are installed, or (with permission) by editing the original.init file.
There are thousands of clones of Tetris, you know. Legally they cannot be called "Tetris" because the name is trademarked, and they can't use the Russian music because that music is copyrighted.
There is no way even Microsoft could survive the lawsuits if you could not sell (or give away) software with a disclaimer of liability.
I would think the only thing left would be freely-traded software where the original source is very carefully hidden so it is impossible to locate who to sue, and VERY expensive software from companies that buy VERY expensive insurance policies.
The free software would certainly be almost 100% of what is run anywhere and would include source code, but it would be a very strange version of open source. Even if you have a bug fix you may have to disguise the fact that it is your fix, and you would have to post it anonymously and publicly so the original maintainers will hopefully see it and incorporate it into their anonymous distribution. And nobody could get any credit for creating something, which I think is about 50% of the drive behind open source software today. And if you buy hardware it is likely to come with a tiny piece of (insured) software that presents a lot of legalize and lets you download the operating software, with clear indications that you are volutarily installing this software from a source that is not the hardware manufacturer.
Slashdot Mirror
Wrong. In official Microsoft documentation before Windows 98, it was Ctrl+Insert for copy, Shift+Insert for Paste, and Shift+Delete for cut. Around Windows 3.1 many programs ignored this and copied the Macintosh and used Alt+C,X,V. In Windows 95 Microsoft finally gave up and made it Ctrl+C,X,V (they wanted Ctrl for menu shortcuts to avoid conflicts with foreign keyboards that used Alt as an extra shift key).
The three icons were added in Windows 95. In earlier versions closing the window was done by double-clicking the top-left button.
Now go hang your head in shame for such blatant mis-information.
BZZT. That's a server and general-Linux article.
Please find an article that says "Year of Linux ON THE DESKTOP"
In reality, copyright violations and stolen code are far more likely in closed-source. This is for the simple and obvious reason that it is a lot easier to hide the fact that you did it because far fewer people see it. I'm not talking about a company willingly stealing code, I am talking about the individual developers and contractors working for that company who are quite willing to steal and cheat to get their job done and hope the boss does not notice. OSS contributors cannot do this because they know the code will be looked at by thousands of people, at least half of who do not have an interest in using the code and may actively want to find a reason to reject your code (ie because they have their own competing contribution). Compare this to a company where at most a few dozen people look at the contributed code and all of them are interested in having the project done.
Okay, I tried it again. I can set "Inactive inner window" to "Activate and pass click". But this does not work, it still raises the window. Since I'm also using point-to-type I suspect it thinks the window is not "inactive", but there is no option for "active inner window" for me to change. I'm sorry, but it appears they do not test this, so it does not work and is useless.
Besides I stand by my original assertion that if they just defaulted to not doing anything, it would be trivial for programs that want the current behavior to replicate it by raising their own windows. The fact is my software cannot assumme it can avoid this greatly limits my choices. Our software really wants to display several image viewers of 1024 pixels wide or larger, with controls the user can manipulate in them, usually they want to move the controls in one small area while referring to a different image. On Irix using 4DWM this was trivial and quite intuitive to extreme novice users, they could grab the window titles and slide the windows so the part they are interested in was visible, and then manipulate them all they want, and never lose sight of the information they wanted to see.
On Windows and Linux I am forced to zoom way out so the windows can be made small enough so that they don't overlap, and use non-integer zoom so they are not so tiny as to be useless, this results in very ugly images, despite the fact that we are using very high-quality filtering, compared to the very smooth and instantaenouse 1:1 or 1:2 scaling that we could do on the "old fashined" Irix system, and details like dust and bad edge pixels are lost, and the user can easily be misled as to whether they have lined up images with each other, resulting in expense and wasted time when these mistakes are not detected until filmout. The screen space used by the title bar is useless, as the user cannot move the window in any useful way, instead they have to use the panning controls in the program to move the image inside the window. Any attempt to move or change the size of the window requires fiddling with the size of the other windows so they don't overlap, a tedious waste of time. Most software is forced to go to a tiled layout to solve this tedious resizing, but I don't want to do that because it requires a parent window and large empty useless areas in it, at least with sepearte windows they can put their IM client or other things in the holes and use them.
They may think they are offering choice, but mindless copying of Windows means they don't test alternatives sufficently that you can use them. In KDE, turning off the click-to-raise also turns off the ability to raise windows by clicking on the title bar, which is not very useful or user friendly. Also all CDE-style window managers (and Windows) have a bug where if you raise a "child" window, it also raises it's parent to immediately below the child. This is just as bad as raising a window when you click inside it, and I have not seen a single modern window manager that does not have this bug. (my window manager flwm does not have this bug, so at least it proves that it can be avoided).
More importantly, as long as programs cannot assumme they can avoid click-to-top, they have to work around it. This means making child windows even when they are not modal, and using single-window/dockable/tiled/MDI type interfaces.
The biggest annoyance is that if they would just turn it off, it is trivial for programs that want click-to-top to turn it back on (all they have to do is raise themselves in response to a click). The opposite is not true, I have no way to avoid raise-to-top (except elaborate kludges with messing with the TRANSIENT_FOR property which can fool some window managers). If they would turn this off permanently they would really be offering "choice".
Um, MDI literally means MULTIPLE DOCUMENT INTERFACE. Notice the word MULTIPLE. This means that several documents are in windows that are framed by another window. MDI was designed for exactly one purpose: to avoid swapping in other programs by avoiding the need to expose their windows when the user moved the window they were working on. This was necessary when Windows 3.1 came out (before that Microsoft tried to tile the entire window system, similar to the old Andrew window system and Lisp machines). This is absolutely and utterly obsolete nowadays.
I suspect you are actually talking about framing different windows that make up the interface to one document, such as various toolbars and control panels, so that they all move together. On more modern programs they are often "tiled" to be adjacent to each other and you cannot overlap them.
Please don't call that "MDI", as the term in wrong. Perhaps "single window interface" is more accurate, especially with the newer tiled ones.
Personally I don't think single window interface is necessary, except for an annoying bug that is in Windows and has been copied on all the modern Linux desktops: the fact that clicking inside windows raises them to the top. This makes use of overlapping windows almost impossible, and has forced everybody to go to a tiled arrangement, or framing a hierarchy of child windows, so that the raised windows do not obscure important things.
It would also be helpful if windows could be identified as belonging together in some way other than the child stacking order, so that iconizing the main document could hide them all, and they only take one entry in the taskbar. This is the other reason for the single window interface (in programs like Photoshop which still allow overlapping inner windows), and a lot of the reason for multiple desktops in Linux.
The Windows POSIX was purposely designed to not interoperate with other programs in order to discourage it's use. Microsoft wrote it only to fulfill government purchasing requirements.
Both this thing and cygwin read and write the same files with the same names as Windows-native programs, and do many other things that would seem obvious but the POSIX system does not do.
More accurately ctrl.alt.+/- just change how the screen memory is mapped to the screen, so you see a subrectangle. As far as I know, there is no way for a program to even find out that it is happening.
I'm unsure what the point is today with LCD screens, however. Running at any resolution other than the matching one looks like crap, so this idea is entirely obsolete.
I think a lot of this "change resolution requirement" is due to the fact that Windows did it, so people all said "it's intuititive and useful". I'll bet if Windows had fixed resolution and changing it was some feature of Linux, we'd have lots of people complaining about this "useless frill that just confuses users, why can't we leave the windows where they were?", while Linux zealots would be claiming that resoultion-changes is proof positive that Linux is the best thing in the world!
In 1985 just before the Macintosh came out, the standard on PC's was to use the numbered function keys for cut & paste (and for every other action). About the only real "standard" was that Microsoft Word (the DOS version) used Shift+Delete, Ctrl+Insert and Shift+Insert, and due to the fortunate fact that few other programs had assigned anything to those keys, other software was easily able to copy this, so there was a bit of uniformity. Except for Emacs clones, I never saw any software use Ctrl+letters for anything, typing them either inserted smily faces or inserted ^X notation.
The Macintosh definately standardized on the Apple+X,+C, and +V for cut, copy, paste. Also on Apple+Z for Undo. The X and C sort of make sense from a menemoic point of view, but it is pretty obvious these were selected for their positions on the Querty keyboard. I have no idea if Apple copied this layout from Xerox or anywhere else (like Apple II applications?)
After that you started see Mac-like programs on PC's and on Unix workstations such as Sun. I never saw one from that age that did not use Alt+X,Alt+C, and Alt+V for these actions. Compare a Mac and a PC keyboard from this era and it should be pretty obvious why Alt was chosen: the keys are in the same place. This is the source of the large number of Linux programs that "use Alt instead of Ctrl and are therefore inconsistent". The first versions of Windows (ie before 3) used Alt as the standard key for menu shortcuts, although Microsoft denies this, but I worked with those versions so I know. At that time Microsoft was still pushing the Shift+Insert idea as the "Windows standard" and these were displayed in the menus for the cut/copy/paste items.
For some reason (my best guess is due to conflicts with foreign keyboards which used the Alt key for shifting some keys to get foreign letters), in Windows 3.1 Microsoft changed the standard menu item shortcut binding from Alt to Ctrl. They also appeared to give up their attempt to be different than the Mac and made menu items for cut/copy/paste with Ctrl+x, ctrl+c, and ctrl+v shortcuts, hiding the shift+insert stuff (though they still work).
By "everything has to be rasterized" he is probably talking about the fact that you cannot draw antialiased anything on current X except by drawing the resulting composite into a local bitmap and sending it. I agree with the original poster that this is a problem with the absurdly primitive X rendering model. But an interface whereby which anything describable by even PostScript can be rendered by the server does not exist on any platform, except perhaps OS/X.
A more accurate criticism of X is that they refused to add even the simplest "draw this image with alpha". This would get rid of about 90% of the reason GTK and other toolkits have to draw all their graphics in local memory and send it. Anti-aliased lines and shapes would be nice but Microsoft doesn't seem to be in any rush to do them either...
KMail has always worked with SMTP for me, without any changes. I also find it hard to believe that anybody would claim rebooting would fix it if it was broken, so I think you are making this up.
I am annoyed that the command-line "mail" does not work, however, and I have to use KMail to send everything. How come the fancy GUI tools work while the basic building blocks don't? This is actually the fundemental problem software engineers have with Windows, and it seems Linux is duplicating those problems as fast as it can.
What the hell are you talking about? Did you even try typing Ctrl+X and Ctrl+V? It works in every single modern program out there, IDENTICALLY to Windows!
The middle-mouse click is drag and drop, not cut & paste. Pretend it doesn't exist and maybe you will see the light. A Windows-only user would probably have an easier time than you are having...
Your post is strange. The complaint about Linux is that stuff *OTHER* than text does not work. The numbers in your spreadsheet will cut and paste just fine. Try it. Cutting & pasting images does not work, and this is entirely on the brain-dead "pure" design the original ICCCM people did back when Unix design was being dictated by the OSF and other buracracies. (basically the problem is that although the design is almost identical to Windows, the ICCCM said "here is where you put the number identifying the type of data, but we won't say what the numbers should be because that is not our job", while at the same time Microsoft said "hey if you put a 14 in there it means a .BMP file" (note the number is not correct, but that is the idea).
Also, I challenge you to find any modern program that does not use Ctrl+X and Ctrl+V for cut and paste (yes the middle-mouse stuff works as well, but that does not mean the Windows shortcuts don't work).
If you say "Emacs" or anything like that, I would like to point out that cut & paste don't work in Emacs on Windows either. I mean MODERN programs, ie written after Windows 98 came out, which is when all the programs you are comparing to on Windows date from.
There are *TWO* different things that are commonly called "alphablending" and they are suprisingly unrelated.
One of them is just the ability to draw a thing that is "partially transparent" atop another thing. You can't "take them apart" later, the only thing stored is the resulting composite. Until 2 years ago this is 100% of what people were thinking of when they said "alpha" and IMHO it is also vitally more important than the other problem, described below. This is addressed in the current XFree86 with the XRender extension. The main use you may have seen of this is for anti-aliased text, however it can also be used to draw transparent images or to draw antialiased filled shapes and curves. The XRender API is way too hard to use, so a project called Cairo is writing a new graphics library atop it to address this.
The other, UNRELATED, thing is basically "back buffer with alpha and hardware compositing to the screen for each window". This is used to make "transparent windows" and shadows. It could also be used in a much more useful way to produce shaped windows with anti-aliased edges, though I have not seen this done even on the Mac. This does not exist in available XFree86 implementations, though it is in the development versions from Freedesktop.org. It is not as far along. Unfortunatly this rather unimportant piece of eye candy is now what everybody talks about when saying "alphablending" and especially on the Mac and Windows is being used and developed much more extensively than the much more useful antialiased drawing of images.
My ISP runs SpamAssassin and markes the spam in the subject lines. I think a good idea would be if a user approaches their storage limit, that the ISP then deletes all the SpamAssassin-marked mail. This is certainly better than deleting all the *new* mail, which seems to be the solution my ISP uses. It could delete everything higher than 5, then 4, then 3, etc, until the amount of email falls below the limit.
It would also help if the ISP had an option on the web page that said "throw away anything Spam Assassin thinks is spam". A user could turn it on if they decided SpamAssassin was doing a good job. I put a cron job in my ISP to do this (they provide a Unix shell) but I doubt that would ever be considered user-friendly.
The GPL does not restrict any rights that you have naturally under copyright law. You can "copy for fair use" the GPL source code all you want, put it on every machine you own, print it out, etc. The reason you cannot use it in a closed-source program and then sell or distribute the program is that you are violating copyright, not the GPL. The reason you can distribute the program with source code that is also GPL covered, is that the GPL explicitly says that if you follow those rules you are allowed to violate the copyright.
However, a Sun spokesperson said Green actually tendered his resignation "long before last week. It was coincidental timing, not related timing."
You mean to say that there was no indication to a top internal person that the decision to accept a 2B payoff was being considered, until exactly when it happened? Almost certainly he agreed to wait until the decision was announced before he quit. The fact that he decided "long before" does not mean it was unrelated...
Well you can also add plugins directly to the installation. But some may consider 3rd party plugins as not being part of the application and actually something else, so they should not be there. I mean you could consider every single program on Linux to be a "plugin for Linux" and thus they should all be in the one "Linux directory".
I feel installations that look in multiple places are ok as long as there is no requirement that those multiple places exist. The user can delete their ~/.app directory and the program still works, they just lose their plugins.
(note also that when I say ~/.app, I mean ~/.<name_of_app>)
Hard as it is to believe, it is even what techophiles believe to be the correct procedure. Only long exposure to Windows or Unix brainwashes people into thinking anything else.
It should be possible to use a hash to find identical copy-on-write pages loaded by the system and share them. This should allow non-shared libraries to become "shared" in memory, and would probably reduce memory usage. There may be startup-time issues, though: no matter how fast the hash is (even precomputed and on-disk), if there is a "hit" it has to compare the full 4K to make sure, so the better the sharing works, the slower programs load...
The problem with plugins is that they require the functions they call to be in a shared library (actually not a problem on Linux if you link with -shared, but we had to support Windows too, so we had to solve this).
/proc/self/exe). It modifies the LD_LIBRARY_PATH to add this directory, and then execs the real program from the directory. This step is not needed on Windows, where the program's directory is always added to the library search path.
.init file.
In our software *everything* in in a single directory. What is there is:
1. A tiny "exec" program named after our app. This program figures out what directory it is in (from
2. The real program
3. A shared library containing everything our plugins need.
4. A subdirectory containing all the plugins we provide with the program.
5. An "init" file that is text-editable. But by default it looks in ~/.app/ for the plugins as well as the plugins subdirectory. It will also source identical files in the ~/.app directory. So if you have your own plugins, you can add them by putting them in your home directory, by modifying the init in your home to point where they are installed, or (with permission) by editing the original
There are thousands of clones of Tetris, you know. Legally they cannot be called "Tetris" because the name is trademarked, and they can't use the Russian music because that music is copyrighted.
There is no way even Microsoft could survive the lawsuits if you could not sell (or give away) software with a disclaimer of liability.
I would think the only thing left would be freely-traded software where the original source is very carefully hidden so it is impossible to locate who to sue, and VERY expensive software from companies that buy VERY expensive insurance policies.
The free software would certainly be almost 100% of what is run anywhere and would include source code, but it would be a very strange version of open source. Even if you have a bug fix you may have to disguise the fact that it is your fix, and you would have to post it anonymously and publicly so the original maintainers will hopefully see it and incorporate it into their anonymous distribution. And nobody could get any credit for creating something, which I think is about 50% of the drive behind open source software today. And if you buy hardware it is likely to come with a tiny piece of (insured) software that presents a lot of legalize and lets you download the operating software, with clear indications that you are volutarily installing this software from a source that is not the hardware manufacturer.
Actually a better example might be the Linux-based router.
Actually it is pretty likely Mozart would be very good at Perl, if he bothered to learn it.