These ideas are not totally pointless, but have a few problems:
Provide one windows manager.
Yes this would be reasonable, and KDE is doing this now. But we need to get stupid design decisions out of these systems, or we are stuck with the crap that is Windows. I want a standard that does not copy the Windows mistakes and restores some nice behavior from older Unix systems: support point-to-type, don't raise windows on clicks, allow you to drag a window without raising it, make middle mouse click lower windows, and don't treat push,release,push as a double click (use push,release,push,NO DRAG,RELEASE, goddammit!!!) The window manager should copy the good ideas from Windows: trap very few keystrokes (ie Alt+Tab is probably the only one needed), cycle between windows whether they are iconized or not, "icons" (taskbar) are text and they appear whether or not the window is visible.
Provide one shell.
Actually the things a novice user needs to type are identical in all shells, except one: the sh based shells should add a "setenv" command with syntax identical to the csh shells. Shells should have every single possible file and command name completion option turned on by default!
Provide a unified Linux look and feel
Here I disagree with conventional wisdom. I think this "look" argument is bogus, and would like to see a single example of a user who is "confused" because the borders on buttons look different between programs. This is total nonsense and is being used to force bloating slow toolkits down our throats. "feel" is legitimate, but has really been fixed, only very old programs still use those horrid Athena scrollbars.
Remove options.
That is not as stupid as some people here think. Many options are where the programmer could not pick a course of action or is scared of alienating some portion of her audience, or the programmer is too lazy to determine something about the system and forces the user to figure it out. Many of these options bloat and complicate code, which is bad for open source, often making it more difficult to modify it to a user's preferences and thus totally counter-productive!
Create a windows manager that couldn?t crash
It is true that the window manager and X is the main comparison with Windows instability. It locking up or crashing is as useless as a Windows crash for the average user. I have personally had it lock the Alt-F terminal switching, making it quite useless even for an advanced user (no I don't have a terminal on the serial port or network connection). The problem is absurd complexity due to back compatability and wimpy design decisions (the same reason Windows is unstable), and the only way to fix it is to jettison back compatability and move some of this mess out to user space.
She also mentions dumping into a shell, which I would immensely prefer over the Windows or Linux behavior of rebooting or logging out, which unfortunately puts you right back into the broken window manager!
MicroSoft is free to examine the source to Linux, make their own changes to it, and experiment with their potential secret evil version. In fact nothing physically prevents them from distributing their evil version, except public perception, and perhaps the threat of a lawsuit.
The equivalent for music would be if I could easily play, copy, or mess with the music data in any way I want. I could even post it on the net or give it to other people. However if I post it, escpecially for sale, I do risk the wrath of the RIAA, since I have obviously taken their copyrighted work and tried to profit form it. (I also think Napster is guilty of aiding this sort of illegal activity).
The GNU equivalent for what the RIAA really wants is that the government mandates that all compilers have a switch so that attempts to compile GNU code without posting it to the internet as free source would fail. Anybody trying to circumvent this switch would be caught by the thought police and thrown in jail.
It is apparent to me that they don't care about pirates, and they are using this as an excuse to control the technology.
You can stop the pirates just as well (ie poorly) with a completely open system, provided you make it illegal to sell blank disks without an unwritable track burned into them. It does not matter whether the contents of this track are secret or not, as in either case somebody could outwit this with hardware or software that provides the data on this track. That cannot be prevented, but if all commercial devices cannot do this it would make the bulk pirates job a lot harder!
Since the existing scheme does nothing to stop the bulk pirates, it is apparent it's goal is something else. Like many here, I believe it is to control the players, so that users cannot fast forward through ads, and so that a pay-per-view system can be gradually implemented in the future.
You are talking about encryption, not copy protection. Encryption is what prevents an unauthorized person from accessing the data and doing bad things with it. The difference is that the unauthorized person never can look at the data.
Copy protection would be some magic scheme where your Doctor, who needs to refer to your medical records, is somehow only able to use that information for good. This is physically impossible!
I think you will find huge support for encyrption here! It is different than copy protection.
A very simple counter-example, where enforced policy is causing trouble. Since you mention some amazing command-line parsing interface, I think this is a good example of this! In this case I think Windows does things right and Unix does them wrong.
Unix does do some interface to enforce policy: the shell splits commands at the spaces and does glob expansion and quoting. Windows does not, it passes the typed line unchanged to the program.
Yes, this results in some inconsistency of Windows programs, but really very little. Most programs call some function when they encounter a word with '*' or '?' in it. Most of the inconsistency is people working around their stupid decision to use the directory seperator '/' to introduce switches. This is trivial to do beacuse Windows does not enforce such policy, but like you said it results in inconsistency. But I still feel the result is better than if we were forced to use '/' to introduce switches.
But one of the immediate questions people familiar with DOS asked about Unix is "where is the 'rename *.A *.B' command?" Unix people, being sometimes illogical in their defense, will go on about this being undesirable or bad computer science, but the real answer is that Unix's "policy" is preventing a very logical user interface design!
Another good counter-example is X. X admittedly sucks, but the suprising thing is that this primitive thing, designed in 1983 or so, is able to reproduce the GUI that MicroSoft and Apple are writing now. If Unix had done "policy" like you said, we would all be forced now to use the Athena toolkit. The fact that all the applications correctly respond to the "reverse video" configuration option might impress you, but I think most people would immediately dismiss Unix as crap!
I think the point is that this should not be necessary, and that starting a new copy should be faster. I don't think it would be a good idea that there is a daemon running for every application we might want to run! And somehow saying Emacs is special is not a good solution either.
Although tinier, I would also complain about the startup time of all shell scripts except perhaps/bin/sh -f. A lot of Unix design relies on executing these scripts fast, and the original systems did start up these interpreters relatively fast (ie it took less time to start than to run a typical command).
As many people pointed out, nothing prevents "god" from having created the earth with all these similar genomes and everything. In fact, He could have created the earth last thursday, including our genes, all our memories, and all these old SlashDot posts. It is quite impossible to disprove creationism.
However if creationists are religious, they should know that they are violating god's will! It is pretty obvious that god wants us to believe in evolutions.
Think about it: the earth was created with a vast mass of evidence that evolution happened. If everything God does is for a purpose, what is the purpose of this? Obviously God wants us to believe in evolution. Who knows what the punishment is for failing Him and questioning the very things he created? The creationists better watch it, they may be going to hell...
The "theory of evolution" has more proof than the "theory of quantum physics" does. That machine you just used to type in this nonsense on was designed to work assumming the "theory of quantum physics" was true. I can't believe you paid money for it, considering how unlikely in your mind it was that it would work!
What you described is a hand-written implementation of a shared library, so this would be equivalent of taking the GPL code and trying to release it as an LGPL library, ie it is not allowed.
It does not matter how good the interface to Qt is. My point is that this "hard stuff" should not be mixed into Qt or any other toolkit. It totally stifles any ability to write new toolkits or to come up with new user interface ideas.
You might as well put the file system or networking code into Qt while you are at it.
We need to stop this insane design and return to the styles of design that made Unix work. This is the same crap that MicroSoft is handing us, and the fact that I can read the source code is not enough to make up for it!
I want a drawing library that is toolkit independent. This means it CANNOT refer to a widget in any toolkit, and cannot require that it be called only from methods from a toolkit. It really isn't too hard: there should be a static "state" that indicates what you are drawing onto, and you make calls that draw on it (see OpenGL for an example, and also why this is MT safe). Then the toolkit is free to set up the "state" before calling the user's drawing code, and the user is free to reuse their drawing code under different toolkits!
Why it's always "their" data which gets protected and never "mine"?
Probably because it is just as techinically impossible as protecting "their" data, and there is no market for trying to pretend otherwise.
Face it, the problem with both is that the data is useless unless an untrusted individual can read it. The big evil company can then copy it, and so can the little evil music pirate.
I fail to see how copy restricion is going to work to stop the big evil corporation. If they can read the data they can send it to somebody else (the data is much smaller than a piece of music and could be dictated over the phone, probably). I also would not want important information stored on unreliable medium that may become unreadable! Also since the big evil company collected the information, they would be pretty stupid to convert it all to a form that they could not take full advantage of, and not keep the original!
Trying to say that copy restriction will somehow hurt big evil corporations is a pretty stupid attempt to get sympathy for an unpopular position here!
If you think the band earning $10,000 a year gets anything from CD sales, you are sadly mistaken. They would be overjoyed if there was free distribution of their music, ideally with some format that does not allow the deletion of the "call this number to book us" message.
RIGHT ON! I am glad to see that at least one other person agrees with my feelings about these toolkits.
Writing toolkits is for people who are lazy and want to feel like they are doing something good (believe me, I wrote one, fltk). We need to make a core of the hard stuff, like antialiased graphics, and (probably equally hard) make it have a programming interface that mere mortals can comprehend (read the XRender extention description for an example of an interface that fails this criteria, imho. Check up on PostScript or OpenGL for examples that I feel are ok).
X was stable (and in fact pretty much resembled how it is today, sigh) before NeXT was even designed. The reason NeXT didn't use it is that X sucked, the same reason Apple didn't use X today.
However, I personally think the approach of all the alternatives to X, which is to force the "toolkit" down into the low levels of the system, is wrong. What we need is the low-level control like X combined with the powerful graphics of these modern systems. Drawing a button and making the mouse click it is trivial, guys, in fact it is probably easier than any of the horrendously complex toolkit interfaces we have developed, including SlashDot faves like Qt, KDE, or even my own fltk.
While drawing a dithered image with transformations, or interpreting UTF-8 and correctly formatting all the Unicode characters, is HARD. Stop wasting your and my time with these toolkits and get to work on the HARD parts! Thank you!
The problem is that the purpose of the encryption is to enforce the region coding (and other rules, like not being able to fast-forward through the FBI notice or ads). The encryption does nothing to prevent copying.
Think about it. The average user cannot copy the disk because the "blank" disks have an area burnt into them that contains data necessary for the playing of the disk. (real money-making pirates have no trouble getting "real" blank disks, so this does nothing to them). There is no reason for the contents of this area to be secret, you would be unable to play the copied disk anyway because the necessary data is missing. Other schemes that would work are "intelligent" DVD burners that would refuse to write anything recognized as a DVD, thus destroying the data so bad that it is useless. (Of course SlashDot would hate this stuff as well, but I am just pointing out that the "encryption" has nothing to do with piracy prevention).
The encryption's job is to make it impossible to get the data off the disk into viewable form without using a program under the manufacturers control, thus linking you to other "features" of this program that are not in your interest.
It is true that one of the "features" is that you cannot send the decoded output to storage. This does interfere with piracy. But not much, as still nothing is preventing the contents of the DVD from being copied to another storage, and I doubt there is much technical obstacles stopping the DVD player from being fooled into reading from this storage instead.
I believe the "RTTI overhead" is also in Java. It does not magically do this in some way that the C++ compiler can't!
Conversely, though, RTTI would be simple and almost free (the vtbl pointer could be used and a single pointer added to it to point to the parent vtbl) if it wern't for damn multiple inheritance. C++ really fell down when they gave into the demands of those idiots who wanted multiple inheritance for non-pure-virtual objects. I do believe everything could have been done with a single parent, and some syntax for invisible ONE WAY casting to the other "parent" types, ie the class is only of one type, but can be easily used in calls that accept any of the other "parent" types.
This "requirement" of the LGPL is, imho, extremely harmful to the ability to distribute small projects (like my own toolkit fltk) under the LGPL. It makes what could be a simple program for the end user into an "install" nightmare. I just explicitly say "you can statically link" but I have not dared change the wording of the LGPL because I don't want to do "yet another license".
It is not clear if the LGPL really says this, anyway. It says you must provide a way to relink the program. I think making the user send their new copy of the library to you and relinking it for them would satisfy this requirement. More pratically, providing.o files on request would work, or providing the source code under NDA would be ok.
I also see no purpose in this requirement. I cannot believe anybody will use it to replace small libraries like mine. Any fix that would allow it to still link would be a bug fix and I would be much more interested in having the user be forced to reveal the bug fix! New functionality in the library is unlikely to be used by an already-compiled program.
Anyway, I have asked dozens of times for anybody in authority to confirm or deny this "LGPL requires dynamic linking" statement. Also, if it does, I would like official word from GNU as to how to modify my license to delete this requirement without breaking the rest of it!
You may be overestimating the size of static linking. Much of the library size is symbols, which are of course not needed after static linking!
There is lots of other overhead of shared libraries, which people seem to be blind to. The overhead on each call is not zero (on the best systems it is only significant on the first call, but even then I suspect there is overhead because of non-contiguous locations of procedures verses static linking).
I don't see how putting the shared library into the bundle is going to help. If the system could identify it as matching another shared library and thus sharing, we would not have the dll problem in the first place, as that same library could reside where libraries normally do. If not, you have just added all the overhead of static linking AND the overhead of shared libraries.
One invention (or accident) of Windows (and copied by KDE and Gnome) is that you double-click a file and it locates the correct program to run and follows some rules to run that program and tell it the file to work on.
This is often mentioned as an advantage of GUI, but the odd thing is that this has nothing to do with the graphical nature of GUI, and could be easily done with CLI. The problem is that the data structures that control this are totally intertwinded into the GUI code on both Unix and Windows.
Windoze at least provides a command-line program called "start". We really ought to copy this, with a few Unix additions:
Just typing "start x" will act as though you double-clicked the file x in a typical GUI. Typing "start prog" where prog is executable would be the same as "prog&".
"start" would redirect it's I/O to gui programs that popup simple displays when the first text is printed or requested. Possibly an error terminal that is red. If the i/o of start is redirected already this is not done, allowing it to be used in pipes.
The GUI's should be rewritten to run "start" rather than their own code. This would go a long way to making KDE and Gnome cooperate on launching programs. "start" would of course be quite complex as it needs to understand the databases set up by kde and gnome, but perhaps a single better standard could be invented later.
Eventually I expect shells to automatically run "start" if the user types the name of a file on a line by itself.
That's bogus. You might as well complain that an old terminal has 1920 "independent active elements" (24x80).
All advanced gui's I have seen let you fill in a whole lot of fields, and then eventually you push a button and something happens. This is exactly like a CLI when you push return.
The advantage of GUI is that all possible options are presented to you, so you can find out what they are, and don't have to remember anything in order to use all possibilities. Conversely, the advantage of CLI is that the number of possibilities can exceed the display capabilities of your device, possibly astronomically.
After you have expressed these possibilities, I'm afraid both CLI and GUI have an effective "execute" button.
Easy, check if $DISPLAY is set or not. Not being set means no gui.
I have also used -t as a switch to indicate that no GUI is needed (it stands for "terminal"). This certainly is not standard. My usual implementation is to unset the DISPLAY environment variable. This will work with libraries that check DISPLAY.
Slashdot Mirror
Provide one windows manager.
Yes this would be reasonable, and KDE is doing this now. But we need to get stupid design decisions out of these systems, or we are stuck with the crap that is Windows. I want a standard that does not copy the Windows mistakes and restores some nice behavior from older Unix systems: support point-to-type, don't raise windows on clicks, allow you to drag a window without raising it, make middle mouse click lower windows, and don't treat push,release,push as a double click (use push,release,push,NO DRAG,RELEASE, goddammit!!!) The window manager should copy the good ideas from Windows: trap very few keystrokes (ie Alt+Tab is probably the only one needed), cycle between windows whether they are iconized or not, "icons" (taskbar) are text and they appear whether or not the window is visible.
Provide one shell.
Actually the things a novice user needs to type are identical in all shells, except one: the sh based shells should add a "setenv" command with syntax identical to the csh shells. Shells should have every single possible file and command name completion option turned on by default!
Provide a unified Linux look and feel
Here I disagree with conventional wisdom. I think this "look" argument is bogus, and would like to see a single example of a user who is "confused" because the borders on buttons look different between programs. This is total nonsense and is being used to force bloating slow toolkits down our throats. "feel" is legitimate, but has really been fixed, only very old programs still use those horrid Athena scrollbars.
Remove options.
That is not as stupid as some people here think. Many options are where the programmer could not pick a course of action or is scared of alienating some portion of her audience, or the programmer is too lazy to determine something about the system and forces the user to figure it out. Many of these options bloat and complicate code, which is bad for open source, often making it more difficult to modify it to a user's preferences and thus totally counter-productive!
Create a windows manager that couldn?t crash
It is true that the window manager and X is the main comparison with Windows instability. It locking up or crashing is as useless as a Windows crash for the average user. I have personally had it lock the Alt-F terminal switching, making it quite useless even for an advanced user (no I don't have a terminal on the serial port or network connection). The problem is absurd complexity due to back compatability and wimpy design decisions (the same reason Windows is unstable), and the only way to fix it is to jettison back compatability and move some of this mess out to user space.
She also mentions dumping into a shell, which I would immensely prefer over the Windows or Linux behavior of rebooting or logging out, which unfortunately puts you right back into the broken window manager!
The equivalent for music would be if I could easily play, copy, or mess with the music data in any way I want. I could even post it on the net or give it to other people. However if I post it, escpecially for sale, I do risk the wrath of the RIAA, since I have obviously taken their copyrighted work and tried to profit form it. (I also think Napster is guilty of aiding this sort of illegal activity).
The GNU equivalent for what the RIAA really wants is that the government mandates that all compilers have a switch so that attempts to compile GNU code without posting it to the internet as free source would fail. Anybody trying to circumvent this switch would be caught by the thought police and thrown in jail.
That is the difference between the two positions.
Kind of like that prior use thing in patents.
And they really are not very expensive.
You can stop the pirates just as well (ie poorly) with a completely open system, provided you make it illegal to sell blank disks without an unwritable track burned into them. It does not matter whether the contents of this track are secret or not, as in either case somebody could outwit this with hardware or software that provides the data on this track. That cannot be prevented, but if all commercial devices cannot do this it would make the bulk pirates job a lot harder!
Since the existing scheme does nothing to stop the bulk pirates, it is apparent it's goal is something else. Like many here, I believe it is to control the players, so that users cannot fast forward through ads, and so that a pay-per-view system can be gradually implemented in the future.
Copy protection would be some magic scheme where your Doctor, who needs to refer to your medical records, is somehow only able to use that information for good. This is physically impossible!
I think you will find huge support for encyrption here! It is different than copy protection.
A very simple counter-example, where enforced policy is causing trouble. Since you mention some amazing command-line parsing interface, I think this is a good example of this! In this case I think Windows does things right and Unix does them wrong.
Unix does do some interface to enforce policy: the shell splits commands at the spaces and does glob expansion and quoting. Windows does not, it passes the typed line unchanged to the program.
Yes, this results in some inconsistency of Windows programs, but really very little. Most programs call some function when they encounter a word with '*' or '?' in it. Most of the inconsistency is people working around their stupid decision to use the directory seperator '/' to introduce switches. This is trivial to do beacuse Windows does not enforce such policy, but like you said it results in inconsistency. But I still feel the result is better than if we were forced to use '/' to introduce switches.
But one of the immediate questions people familiar with DOS asked about Unix is "where is the 'rename *.A *.B' command?" Unix people, being sometimes illogical in their defense, will go on about this being undesirable or bad computer science, but the real answer is that Unix's "policy" is preventing a very logical user interface design!
Another good counter-example is X. X admittedly sucks, but the suprising thing is that this primitive thing, designed in 1983 or so, is able to reproduce the GUI that MicroSoft and Apple are writing now. If Unix had done "policy" like you said, we would all be forced now to use the Athena toolkit. The fact that all the applications correctly respond to the "reverse video" configuration option might impress you, but I think most people would immediately dismiss Unix as crap!
Although tinier, I would also complain about the startup time of all shell scripts except perhaps /bin/sh -f. A lot of Unix design relies on executing these scripts fast, and the original systems did start up these interpreters relatively fast (ie it took less time to start than to run a typical command).
However if creationists are religious, they should know that they are violating god's will! It is pretty obvious that god wants us to believe in evolutions.
Think about it: the earth was created with a vast mass of evidence that evolution happened. If everything God does is for a purpose, what is the purpose of this? Obviously God wants us to believe in evolution. Who knows what the punishment is for failing Him and questioning the very things he created? The creationists better watch it, they may be going to hell...
The "theory of evolution" has more proof than the "theory of quantum physics" does. That machine you just used to type in this nonsense on was designed to work assumming the "theory of quantum physics" was true. I can't believe you paid money for it, considering how unlikely in your mind it was that it would work!
What you described is a hand-written implementation of a shared library, so this would be equivalent of taking the GPL code and trying to release it as an LGPL library, ie it is not allowed.
You might as well put the file system or networking code into Qt while you are at it.
We need to stop this insane design and return to the styles of design that made Unix work. This is the same crap that MicroSoft is handing us, and the fact that I can read the source code is not enough to make up for it!
I want a drawing library that is toolkit independent. This means it CANNOT refer to a widget in any toolkit, and cannot require that it be called only from methods from a toolkit. It really isn't too hard: there should be a static "state" that indicates what you are drawing onto, and you make calls that draw on it (see OpenGL for an example, and also why this is MT safe). Then the toolkit is free to set up the "state" before calling the user's drawing code, and the user is free to reuse their drawing code under different toolkits!
My machine must be broken, I tried "save as" on several corporate web pages and it worked. Gee, those poor souls, they are out of business!
Probably because it is just as techinically impossible as protecting "their" data, and there is no market for trying to pretend otherwise.
Face it, the problem with both is that the data is useless unless an untrusted individual can read it. The big evil company can then copy it, and so can the little evil music pirate.
Trying to say that copy restriction will somehow hurt big evil corporations is a pretty stupid attempt to get sympathy for an unpopular position here!
If you think the band earning $10,000 a year gets anything from CD sales, you are sadly mistaken. They would be overjoyed if there was free distribution of their music, ideally with some format that does not allow the deletion of the "call this number to book us" message.
Writing toolkits is for people who are lazy and want to feel like they are doing something good (believe me, I wrote one, fltk). We need to make a core of the hard stuff, like antialiased graphics, and (probably equally hard) make it have a programming interface that mere mortals can comprehend (read the XRender extention description for an example of an interface that fails this criteria, imho. Check up on PostScript or OpenGL for examples that I feel are ok).
However, I personally think the approach of all the alternatives to X, which is to force the "toolkit" down into the low levels of the system, is wrong. What we need is the low-level control like X combined with the powerful graphics of these modern systems. Drawing a button and making the mouse click it is trivial, guys, in fact it is probably easier than any of the horrendously complex toolkit interfaces we have developed, including SlashDot faves like Qt, KDE, or even my own fltk.
While drawing a dithered image with transformations, or interpreting UTF-8 and correctly formatting all the Unicode characters, is HARD. Stop wasting your and my time with these toolkits and get to work on the HARD parts! Thank you!
Think about it. The average user cannot copy the disk because the "blank" disks have an area burnt into them that contains data necessary for the playing of the disk. (real money-making pirates have no trouble getting "real" blank disks, so this does nothing to them). There is no reason for the contents of this area to be secret, you would be unable to play the copied disk anyway because the necessary data is missing. Other schemes that would work are "intelligent" DVD burners that would refuse to write anything recognized as a DVD, thus destroying the data so bad that it is useless. (Of course SlashDot would hate this stuff as well, but I am just pointing out that the "encryption" has nothing to do with piracy prevention).
The encryption's job is to make it impossible to get the data off the disk into viewable form without using a program under the manufacturers control, thus linking you to other "features" of this program that are not in your interest.
It is true that one of the "features" is that you cannot send the decoded output to storage. This does interfere with piracy. But not much, as still nothing is preventing the contents of the DVD from being copied to another storage, and I doubt there is much technical obstacles stopping the DVD player from being fooled into reading from this storage instead.
Conversely, though, RTTI would be simple and almost free (the vtbl pointer could be used and a single pointer added to it to point to the parent vtbl) if it wern't for damn multiple inheritance. C++ really fell down when they gave into the demands of those idiots who wanted multiple inheritance for non-pure-virtual objects. I do believe everything could have been done with a single parent, and some syntax for invisible ONE WAY casting to the other "parent" types, ie the class is only of one type, but can be easily used in calls that accept any of the other "parent" types.
This "requirement" of the LGPL is, imho, extremely harmful to the ability to distribute small projects (like my own toolkit fltk) under the LGPL. It makes what could be a simple program for the end user into an "install" nightmare. I just explicitly say "you can statically link" but I have not dared change the wording of the LGPL because I don't want to do "yet another license".
It is not clear if the LGPL really says this, anyway. It says you must provide a way to relink the program. I think making the user send their new copy of the library to you and relinking it for them would satisfy this requirement. More pratically, providing .o files on request would work, or providing the source code under NDA would be ok.
I also see no purpose in this requirement. I cannot believe anybody will use it to replace small libraries like mine. Any fix that would allow it to still link would be a bug fix and I would be much more interested in having the user be forced to reveal the bug fix! New functionality in the library is unlikely to be used by an already-compiled program.
Anyway, I have asked dozens of times for anybody in authority to confirm or deny this "LGPL requires dynamic linking" statement. Also, if it does, I would like official word from GNU as to how to modify my license to delete this requirement without breaking the rest of it!
There is lots of other overhead of shared libraries, which people seem to be blind to. The overhead on each call is not zero (on the best systems it is only significant on the first call, but even then I suspect there is overhead because of non-contiguous locations of procedures verses static linking).
I don't see how putting the shared library into the bundle is going to help. If the system could identify it as matching another shared library and thus sharing, we would not have the dll problem in the first place, as that same library could reside where libraries normally do. If not, you have just added all the overhead of static linking AND the overhead of shared libraries.
This is often mentioned as an advantage of GUI, but the odd thing is that this has nothing to do with the graphical nature of GUI, and could be easily done with CLI. The problem is that the data structures that control this are totally intertwinded into the GUI code on both Unix and Windows.
Windoze at least provides a command-line program called "start". We really ought to copy this, with a few Unix additions:
Just typing "start x" will act as though you double-clicked the file x in a typical GUI. Typing "start prog" where prog is executable would be the same as "prog&".
"start" would redirect it's I/O to gui programs that popup simple displays when the first text is printed or requested. Possibly an error terminal that is red. If the i/o of start is redirected already this is not done, allowing it to be used in pipes.
The GUI's should be rewritten to run "start" rather than their own code. This would go a long way to making KDE and Gnome cooperate on launching programs. "start" would of course be quite complex as it needs to understand the databases set up by kde and gnome, but perhaps a single better standard could be invented later.
Eventually I expect shells to automatically run "start" if the user types the name of a file on a line by itself.
All advanced gui's I have seen let you fill in a whole lot of fields, and then eventually you push a button and something happens. This is exactly like a CLI when you push return.
The advantage of GUI is that all possible options are presented to you, so you can find out what they are, and don't have to remember anything in order to use all possibilities. Conversely, the advantage of CLI is that the number of possibilities can exceed the display capabilities of your device, possibly astronomically.
After you have expressed these possibilities, I'm afraid both CLI and GUI have an effective "execute" button.
I have also used -t as a switch to indicate that no GUI is needed (it stands for "terminal"). This certainly is not standard. My usual implementation is to unset the DISPLAY environment variable. This will work with libraries that check DISPLAY.