Hmm, on Windows I just tried Emacs, and then tried Pine through a telnet connection, and tried cmd.exe, and several other equivalents. My god, they all had the exact same problems. This is proof positive that Windows Sucks, since it seems to be proof that Linux sucks...
*ALL* the modern toolkits use the exact same ctrl+x/v keys for cut and paste, and use selection/middle-click to modify a seperate selection buffer. So multiple toolkits are not the problem.
Interesting analysis, but I think the real problem is a large number of still-existing applications where ctrl+x/v use the SELECTION rather than the CLIPBOARD. To many users this is very confusing to the point where they cannot even tell which program is broken.
There are plenty of X programs where ctrl+Ins/Shift+Ins have the same bug as ctrl+x/v and clobber the SELECTION instead of the CLIPBOARD. In fact I very much doubt there are any programs where these work and ctrl+x/v don't work.
Which is one step shorter than your Windows solution. However on Windows you can drag & drop a selection and this matches the number of operations. But this really proves that middle-mouse paste is a form of drag&drop, a fact that too few people (both those who like X and those who dislike it) are willing to understand.
Unfortunately the select-all-on-click behavior makes it really difficult to edit the text in the address bar (or any combo box). I have certainly had a great deal of frustration trying to change an address to a guessed home page by selecting everything after one of the slashes. On Safari it often drag&drops and produced huge screwups so that the URL is trashed. On Windows you have to click twice which is a little better, but their fix is to make drag & drop not work at all from combo boxes. Not sure if this is too great a solution. Also it seems inconsistent, I know of no text editor where clicking in the text selects all of it, or even a sentence or word.
The problem with X is a large number of applications where the cut/paste commands mess with the middle-mouse buffer. This would be like what would happen if a lot of windows programs messed with the next drag & drop when you did cut/paste, or if when you did a drag&drop it changed the clipboard. Unfortunately the symptoms of the problem are confusing, leading lots of people to blame the programs that are actually working correctly, or suggesting getting rid of drag & drop as a "solution"
Don't be an ass. Ctrl+x and ctrl+v don't work when I run emacs or cmd.exe or hundreds of other programs on Windows either.
The problem is entirely on programs that use ctrl+x and ctrl+v but have them modify the SELECTION buffer. If there were programs on Windows where ctrl+x and ctrl+v clobbered your next drag & drop you would have an equivalent problem. Yes this is a problem with many X applications. However your solutions would be like trying to fix those programs on Windows by deleting the ability to drag & drop. Uninformed criticism like yours is painting everybody who tries to make constructive complaints look stupid.
You don't know what you are talking about. The behavior is dictated by the programs (or the toolkit it uses), not the window manager.
No programs use "their own clipboard/kill ring". There are only two (well there is a third but nobody uses it). The problem is with programs that only use one of these for both the middle-mouse drag&drop and for cut/paste. In fact correct programs are using "their own" but all correct programs use the same one.
Originally X applications would turn off the highlight when they lost ownership of the selection, to try to avoid the "confusion" you are having. Modern programs have realized this is quite a bit worse and they leave the highlighting on.
The middle-mouse is drag & drop, with the advantage that you can rearrange and open/close windows between when you drag and when you drop. When Microsoft announces an "innovation of new move-the-windows drag & drop using the middle mouse button" all the fanboys are going to go gaga, while in the same breath insulting X for having the EXACT SAME FEATURE!!!
That might work if you know what programs are broken and something can be done in X or the window manager to fix it.
Typing ctrl+V would be trapped, and would copy the CLIPBOARD to the SELECTION, and then send ctrl+V. For a really-broken program it could send a middle-mouse click.
Typing ctrl+C or ctrl+X would be trapped and would copy the SELECTION to the CLIPBOARD and then send the key to the program.
These traps would only happen to programs that are known to be broken.
Wrong. In fact KDE and Gnome are doing what they were supposed to be doing all along, at least since the ICCCM standard was written in 1986 or so.
Both KDE and Gnome and every other program that "works" uses the same clipboard, called CLIPBOARD. All programs (I suspect) use the clipboard called SELECTION for when you select text and when you click the middle mouse for paste.
The problem is with programs that use SELECTION for the cut/paste commands. Unfortunatly to the user the correctly-working program appears to be broken, because it pasted the "wrong thing". In fact it was the program you did the cut/copy from that is broken.
There is absolutely no solution except to replace the broken programs. In fact they would be better if you could just disable the cut/copy/paste keys and only let middle-mouse work.
PS: my own code had exactly this problem. I fixed it, and so should everybody else. This is not a problem with KDE or Gnome or with the ICCCM design, it is a very common mistake done by idiots like me who did not realize that the middle-mouse is more like drag & drop than cut & paste.
Re:swap deals with bloat
on
Is Swap Necessary?
·
· Score: 2, Interesting
Unfortunatley that bloat is also *fragmented*. Even a 4-byte structure that is still in use buried in a page will keep it swapped in. In my experience the only way app pages get swapped out is when the app is idle.
Linux will certainly run the same application (or another application using the same shared libraries) much faster the second time. This effect is obvious if your application is over NFS.
I would blame most of the slowness in GUI applications on X, which is not fast no matter what people claim. Try command-line things such as running a script that calls a lot of programs like compilers under tcsh on both systems and it is obvious that Linux exec's non-GUI programs many times faster.
Nonsense. I tried the exploit and it worked. Visiting a web page popped up the finder where it displayed an ftp site, and it then ran a command off this site. It did this all without any intervention of mine except for the initial click to go to that web page. If I clicked and then walked away I would not even see the finder pop up, and I'm not sure if I could have killed it even if I did see the finder. This is a nasty and serious exploit and your denying it is not going to make it go away.
It sounds like the problem is that programs can register as "protocol handlers" and this is done automatically when the finder sees the file. On Windows (and I guess on Linux) this is done only if you actually run a program (and if a web page could cause a program to be run you have a much more direct exploit).
It does seem this could be fixed by not installing any handlers until the program is first run. Not sure how hard this is to do or why Apple has not done it yet. It sould also be the responsibility of anybody doing a protocol handler to not do anything dangerous no matter what command line arguments are passed (perhaps url's should add "--" before any arguments so that switches are never passed, any switches should be done by making different protocol handler names).
Yes Qt would have to be rewritten, but the result will be a better-performing program than one using GDI32. Thus using Qt right now may be an advantage.
If you are allowed to consider programs that worked on character terminals but divided up the screen into windows, I think the term has been used a lot earlier.
How about IBM's "topview", which tried to window MSDOS programs by interrupting the bios calls to update the screen (this failed badly because everybody ignored the bios and wrote to the screen memory).
Earlier there is Unix and VMS (and perhaps others) program "screen" which I found documenttion (copyright 1987, unfortunately) that certainly calls the areas "windows". Also any chance this was based on earlier software, perhaps from Tops20, RSX-11M, or other Dec-based software?
Emacs documentation certainly calls the two halves you get when you type ^X-2 "windows". Any indications when this happened?
I agree it seems hard to believe any term other than "windows" was used to describe these, so there has to be lots of precedence. Did everybody call them "regions" or something? Seems hard to believe.
That was GEM, and it was a little later. Microsoft was already developing Windows at that point and where I worked we had samples of the first versions when GEM came out.
The "screen" command (type man screen) uses the term "window" to indicate an area on the screen (it also uses "virtual terminal" but that is used more like a document, a single window can show different virtual terminals, so these are not equivalent and they definately are using the term "window" for the modern meaning). I do remember "screen" from 1982 on VMS and it was considered old even then. However use of the term "window" may be later, the man page says "Copyright (C) 1987 Oliver Laumann" at the bottom.
The autoconf program would not compile the configure.in file provided with Cairo.
You are right that more problems were probably due to pkgconfig than autoconf. However for the average person smart enough to type "make" these all look like an inpenetrable mess and are all the same thing.
You are missing the fact that most useful applications want to draw a large image of their own design somewhere and allowing the user to click on it and the program can find out where they clicked. Illustrator is probably the best example. Unless Microsoft slows this down so much that Illustrator itself looks bad, that interface will always be available for drawing a portable GUI.
Likely their main reason for making GDI draw a bitmap rather than being a layer atop their new drawing library is that they are very concerned about back-compatability, for instance programs that read the bitmap back. The fact that all "old" programs will run slower is just an added benefit for them. Unfortunately for them, it is very likely that the portable libraries will be quickly rewritten to use the new graphics interface (being portable already they are not so concerned about back compatability). The result will be that Qt apps will be much faster than anything using GDI directly.
More of the threat of Longhorn is that it could provide a useful graphics interface for the average program and eliminate about 50% of the reason people use Qt, which is to use it's portable graphics. The fact that this should have been done 20 years ago is probably lost on all the Microsoft and X fans who don't realize just how horribly bad system design has been for so long. 20 years ago was when PostScript was being developed, and Irix GL already existed. The NeWS window system was also being designed then. Nothing we have today approaches any of those, but maybe Longhorn...
I have RCDefaultApp but I only disabled the disk: and disks:, ftp: is still set to finder. The first demo did nothing. The second one certainly did mount the disk image and opened the finder to show it, but I waited quite awhile (the disk appeared in less than 2 seconds) and nothing happened. Any clues why my machine seems immune?
Case in point: I wanted to compile cairo on my Mandrake 9.1 system. I couldn't until I edited the autoconf file to remove "new commands" and added phony files to make pkgconfig happy. Then it compiled just fine and worked. I tried to compile the demos and was completely frustrated and eventually hand-wrote a trivial makefile and they all compiled just fine and worked (except for the GTK one...). I am now trying to compile the "Glitz" OpenGL backend, and I am running into the same troubles: I can't prove it yet, but I strongly suspect it will compile just fine on my machine, if I can just get around the mysteries and complaints of autoconf/automake/pkgconfig, probably by wasting a great deal of time and divining the basic, and probably simple, Makefile that would compile it.
The incredibly frustrating, and dare I say stupid thing is that the only thing I need to "update" on my machine is the damn autoconf tools! I actually have all the libraries and headers these things need. That is completely backwards! In fact due to autoconf they have pretty much said "this only compiles on the very newest experimental Linux system". Well in that case, you have eliminated the need for "autoconf" and you could send out Makefiles that work only on a new Linux system. That would probably be easier for somebody like me to edit and get working on an older system.
When you do try to fix this, you run into the horrifyingly bad syntax and rules of M4 and GMake. Supposedly this is because they want to be back-compatable and run on older systems. But they lie when they freely add new "autoconf" commands so that the newest version is needed. Why not scrap the whole thing and try a modern syntax?
My proposed solution: make ONE compiled program that does "configure" and "make" and "make depend" (and "install" and "uninstall" and "clean" and "dist" and all the other special-cased targets...). This program can use the existing automake/conf stuff so it can be compiled for multiple platforms. The program then reads one file, in editable text (no XML, and it should be trivial to add/remove a source file by adding/deleting a line). This file should be parsed in a procedural way, with "if" and "for" statements and functions (ie it is perl or something) and the result should be the dependencies tree and it can then run the programs (the result is extremely static and has actual filenames and commands, not templates or "rules"). Make it really easy to add and remove switches to the compiler. Make it save user answers to questions in a file so it can provide those answers again, and make a gui program that provides panels and checkboxes to change those user answers. Make it automatically check for dependencies in any C style source files by looking for "#include" without running the compiler, and save the results in a binary database with date stamps so it can run this instantly as needed. Any package dependenciies should be checked with "if" statements in the file, the program would have enough commands to do typical file system things like look for files or grep a file for something, and it is then trivial to write a file that checks for something in multiple places by using "if-else" statements.
Okay I am now officially old. I was in high school when Star Wars came out.
There was no advance publicity. We lived in the suburbs of Boston, and it was one of the first cities Star Wars was released in.
My family had gotten into watching the reruns of Star Trek on the UHF stations, and I believe by this time had seen most of the episodes and were just turning it on each day to see if either an episode we had not seen, or a "good" episode was on.
The first thing I heard about Star Wars was my Dad saying "there seems to be some rip off of Star Trek in the theatres". He had seen an ad for the movie on TV. Somewhat later I saw the same ad. My first impression was it had to be a British production, done by the Andersons of Thunderbirds and Space 1999 fame, as it certainly looked that style. Despite the fact that American Grafitti was a HUGE hit just a few years earlier and we had all gone to see it, there was no indication of a connection with the director. As I remember it, American Grafitti had just as much impact on popular culture as Jaws.
There was then an absolutley positive review in the Boston Globe for the film. Quotes I remember is that "the robots have more personality than the leads in many films" and the spectacular special effects. That convinced me that I really wanted to see the film. But I did not do much else about that.
It seems that maybe a week later that the public perception and the news reports started indicating that this was an enormous hit of unprecedented proportions. Absolutely there was talk *everywhere* about Star Wars. Though initially only a few people had seen it. The ones I knew said it was "good", though there seemed to be an envious feeling between the "seen it" and "had not seen it" people.
Finally in mid-week my Dad got everybody in the car and we drove to Boston to see it in the big 70mm theatre. Well it turned out that even then, perhaps 2.5 weeks after opening, it was impossible to get in. We instead drove around darkened Boston and looked at the LNG tanker that was tied up there (these were also a big deal, what happened to them?)
I later saw it in midday, perhaps 4 weeks after opening, by then you could buy a ticket for midday and get in. It was fun, and funny, and I was constantly aware that the whole thing seemed to be a spoof or a homage to other adventure films, especially the over-the-top violent bar where nobody thinks much of anybody being killed. Some stuff that seems obvious I missed, for instance I did not identify the big sphere as the "death star" from the title crawl. I also thought the movie was ending when they escaped the death star and was suprised by the battle at the end. Still thinking it was an Anderson production I predicted that they would blow a great deal of stuff up, I did not identify the homage to the WWII fighter movies that the battle actually was. Besides humor and adventure, Star Wars also seemed to deliver a believable universe, and that sand planet seemed to really exist, be planet-sized, and be part of a universe of thousands of such planets, and Luke really did seem to be a tiny figure and the Empire an unstoppable power. No sequel since has been able to be so believable.
Like most good geeks I saw it several times after that, maybe 5. I started to be aware of the audience reactions, such as hissing the villian, something I had never heard in a movie theatre before (or since!)
Star Wars was far bigger than any of the sequels. It was in the news every day, and the fact that it was changing the movie industry forever was obvious and talked about from the first moment!
Slashdot Mirror
Hmm, on Windows I just tried Emacs, and then tried Pine through a telnet connection, and tried cmd.exe, and several other equivalents. My god, they all had the exact same problems. This is proof positive that Windows Sucks, since it seems to be proof that Linux sucks...
*ALL* the modern toolkits use the exact same ctrl+x/v keys for cut and paste, and use selection/middle-click to modify a seperate selection buffer. So multiple toolkits are not the problem.
Interesting analysis, but I think the real problem is a large number of still-existing applications where ctrl+x/v use the SELECTION rather than the CLIPBOARD. To many users this is very confusing to the point where they cannot even tell which program is broken.
There are plenty of X programs where ctrl+Ins/Shift+Ins have the same bug as ctrl+x/v and clobber the SELECTION instead of the CLIPBOARD. In fact I very much doubt there are any programs where these work and ctrl+x/v don't work.
Also in Mozilla and Firefox on Linux you can do:
1. Middle click inside the window
Which is one step shorter than your Windows solution. However on Windows you can drag & drop a selection and this matches the number of operations. But this really proves that middle-mouse paste is a form of drag&drop, a fact that too few people (both those who like X and those who dislike it) are willing to understand.
Unfortunately the select-all-on-click behavior makes it really difficult to edit the text in the address bar (or any combo box). I have certainly had a great deal of frustration trying to change an address to a guessed home page by selecting everything after one of the slashes. On Safari it often drag&drops and produced huge screwups so that the URL is trashed. On Windows you have to click twice which is a little better, but their fix is to make drag & drop not work at all from combo boxes. Not sure if this is too great a solution. Also it seems inconsistent, I know of no text editor where clicking in the text selects all of it, or even a sentence or word.
The problem with X is a large number of applications where the cut/paste commands mess with the middle-mouse buffer. This would be like what would happen if a lot of windows programs messed with the next drag & drop when you did cut/paste, or if when you did a drag&drop it changed the clipboard. Unfortunately the symptoms of the problem are confusing, leading lots of people to blame the programs that are actually working correctly, or suggesting getting rid of drag & drop as a "solution"
Don't be an ass. Ctrl+x and ctrl+v don't work when I run emacs or cmd.exe or hundreds of other programs on Windows either.
The problem is entirely on programs that use ctrl+x and ctrl+v but have them modify the SELECTION buffer. If there were programs on Windows where ctrl+x and ctrl+v clobbered your next drag & drop you would have an equivalent problem. Yes this is a problem with many X applications. However your solutions would be like trying to fix those programs on Windows by deleting the ability to drag & drop. Uninformed criticism like yours is painting everybody who tries to make constructive complaints look stupid.
You don't know what you are talking about. The behavior is dictated by the programs (or the toolkit it uses), not the window manager.
No programs use "their own clipboard/kill ring". There are only two (well there is a third but nobody uses it). The problem is with programs that only use one of these for both the middle-mouse drag&drop and for cut/paste. In fact correct programs are using "their own" but all correct programs use the same one.
Originally X applications would turn off the highlight when they lost ownership of the selection, to try to avoid the "confusion" you are having. Modern programs have realized this is quite a bit worse and they leave the highlighting on.
The middle-mouse is drag & drop, with the advantage that you can rearrange and open/close windows between when you drag and when you drop. When Microsoft announces an "innovation of new move-the-windows drag & drop using the middle mouse button" all the fanboys are going to go gaga, while in the same breath insulting X for having the EXACT SAME FEATURE!!!
How about having drag with the middle mouse select the region to be replaced?
That might work if you know what programs are broken and something can be done in X or the window manager to fix it.
Typing ctrl+V would be trapped, and would copy the CLIPBOARD to the SELECTION, and then send ctrl+V. For a really-broken program it could send a middle-mouse click.
Typing ctrl+C or ctrl+X would be trapped and would copy the SELECTION to the CLIPBOARD and then send the key to the program.
These traps would only happen to programs that are known to be broken.
Wrong. In fact KDE and Gnome are doing what they were supposed to be doing all along, at least since the ICCCM standard was written in 1986 or so.
Both KDE and Gnome and every other program that "works" uses the same clipboard, called CLIPBOARD. All programs (I suspect) use the clipboard called SELECTION for when you select text and when you click the middle mouse for paste.
The problem is with programs that use SELECTION for the cut/paste commands. Unfortunatly to the user the correctly-working program appears to be broken, because it pasted the "wrong thing". In fact it was the program you did the cut/copy from that is broken.
There is absolutely no solution except to replace the broken programs. In fact they would be better if you could just disable the cut/copy/paste keys and only let middle-mouse work.
PS: my own code had exactly this problem. I fixed it, and so should everybody else. This is not a problem with KDE or Gnome or with the ICCCM design, it is a very common mistake done by idiots like me who did not realize that the middle-mouse is more like drag & drop than cut & paste.
Unfortunatley that bloat is also *fragmented*. Even a 4-byte structure that is still in use buried in a page will keep it swapped in. In my experience the only way app pages get swapped out is when the app is idle.
Linux will certainly run the same application (or another application using the same shared libraries) much faster the second time. This effect is obvious if your application is over NFS.
I would blame most of the slowness in GUI applications on X, which is not fast no matter what people claim. Try command-line things such as running a script that calls a lot of programs like compilers under tcsh on both systems and it is obvious that Linux exec's non-GUI programs many times faster.
Dammit, my Ibook is actually on and plugged into the network at home, but the lid is closed, so it ignores me.
Why can't they make it wake up on ssh connections somehow?
Nonsense. I tried the exploit and it worked. Visiting a web page popped up the finder where it displayed an ftp site, and it then ran a command off this site. It did this all without any intervention of mine except for the initial click to go to that web page. If I clicked and then walked away I would not even see the finder pop up, and I'm not sure if I could have killed it even if I did see the finder. This is a nasty and serious exploit and your denying it is not going to make it go away.
It sounds like the problem is that programs can register as "protocol handlers" and this is done automatically when the finder sees the file. On Windows (and I guess on Linux) this is done only if you actually run a program (and if a web page could cause a program to be run you have a much more direct exploit).
It does seem this could be fixed by not installing any handlers until the program is first run. Not sure how hard this is to do or why Apple has not done it yet. It sould also be the responsibility of anybody doing a protocol handler to not do anything dangerous no matter what command line arguments are passed (perhaps url's should add "--" before any arguments so that switches are never passed, any switches should be done by making different protocol handler names).
Yes Qt would have to be rewritten, but the result will be a better-performing program than one using GDI32. Thus using Qt right now may be an advantage.
If you are allowed to consider programs that worked on character terminals but divided up the screen into windows, I think the term has been used a lot earlier.
How about IBM's "topview", which tried to window MSDOS programs by interrupting the bios calls to update the screen (this failed badly because everybody ignored the bios and wrote to the screen memory).
Earlier there is Unix and VMS (and perhaps others) program "screen" which I found documenttion (copyright 1987, unfortunately) that certainly calls the areas "windows". Also any chance this was based on earlier software, perhaps from Tops20, RSX-11M, or other Dec-based software?
Emacs documentation certainly calls the two halves you get when you type ^X-2 "windows". Any indications when this happened?
I agree it seems hard to believe any term other than "windows" was used to describe these, so there has to be lots of precedence. Did everybody call them "regions" or something? Seems hard to believe.
That was GEM, and it was a little later. Microsoft was already developing Windows at that point and where I worked we had samples of the first versions when GEM came out.
It was commonly called X-Windows when it was being developed, in 1983 or maybe even earlier.
The "screen" command (type man screen) uses the term "window" to indicate an area on the screen (it also uses "virtual terminal" but that is used more like a document, a single window can show different virtual terminals, so these are not equivalent and they definately are using the term "window" for the modern meaning). I do remember "screen" from 1982 on VMS and it was considered old even then. However use of the term "window" may be later, the man page says "Copyright (C) 1987 Oliver Laumann" at the bottom.
The autoconf program would not compile the configure.in file provided with Cairo.
You are right that more problems were probably due to pkgconfig than autoconf. However for the average person smart enough to type "make" these all look like an inpenetrable mess and are all the same thing.
You are missing the fact that most useful applications want to draw a large image of their own design somewhere and allowing the user to click on it and the program can find out where they clicked. Illustrator is probably the best example. Unless Microsoft slows this down so much that Illustrator itself looks bad, that interface will always be available for drawing a portable GUI.
Likely their main reason for making GDI draw a bitmap rather than being a layer atop their new drawing library is that they are very concerned about back-compatability, for instance programs that read the bitmap back. The fact that all "old" programs will run slower is just an added benefit for them. Unfortunately for them, it is very likely that the portable libraries will be quickly rewritten to use the new graphics interface (being portable already they are not so concerned about back compatability). The result will be that Qt apps will be much faster than anything using GDI directly.
More of the threat of Longhorn is that it could provide a useful graphics interface for the average program and eliminate about 50% of the reason people use Qt, which is to use it's portable graphics. The fact that this should have been done 20 years ago is probably lost on all the Microsoft and X fans who don't realize just how horribly bad system design has been for so long. 20 years ago was when PostScript was being developed, and Irix GL already existed. The NeWS window system was also being designed then. Nothing we have today approaches any of those, but maybe Longhorn...
I have RCDefaultApp but I only disabled the disk: and disks:, ftp: is still set to finder. The first demo did nothing. The second one certainly did mount the disk image and opened the finder to show it, but I waited quite awhile (the disk appeared in less than 2 seconds) and nothing happened. Any clues why my machine seems immune?
Case in point: I wanted to compile cairo on my Mandrake 9.1 system. I couldn't until I edited the autoconf file to remove "new commands" and added phony files to make pkgconfig happy. Then it compiled just fine and worked. I tried to compile the demos and was completely frustrated and eventually hand-wrote a trivial makefile and they all compiled just fine and worked (except for the GTK one...). I am now trying to compile the "Glitz" OpenGL backend, and I am running into the same troubles: I can't prove it yet, but I strongly suspect it will compile just fine on my machine, if I can just get around the mysteries and complaints of autoconf/automake/pkgconfig, probably by wasting a great deal of time and divining the basic, and probably simple, Makefile that would compile it.
The incredibly frustrating, and dare I say stupid thing is that the only thing I need to "update" on my machine is the damn autoconf tools! I actually have all the libraries and headers these things need. That is completely backwards! In fact due to autoconf they have pretty much said "this only compiles on the very newest experimental Linux system". Well in that case, you have eliminated the need for "autoconf" and you could send out Makefiles that work only on a new Linux system. That would probably be easier for somebody like me to edit and get working on an older system.
When you do try to fix this, you run into the horrifyingly bad syntax and rules of M4 and GMake. Supposedly this is because they want to be back-compatable and run on older systems. But they lie when they freely add new "autoconf" commands so that the newest version is needed. Why not scrap the whole thing and try a modern syntax?
My proposed solution: make ONE compiled program that does "configure" and "make" and "make depend" (and "install" and "uninstall" and "clean" and "dist" and all the other special-cased targets...). This program can use the existing automake/conf stuff so it can be compiled for multiple platforms. The program then reads one file, in editable text (no XML, and it should be trivial to add/remove a source file by adding/deleting a line). This file should be parsed in a procedural way, with "if" and "for" statements and functions (ie it is perl or something) and the result should be the dependencies tree and it can then run the programs (the result is extremely static and has actual filenames and commands, not templates or "rules"). Make it really easy to add and remove switches to the compiler. Make it save user answers to questions in a file so it can provide those answers again, and make a gui program that provides panels and checkboxes to change those user answers. Make it automatically check for dependencies in any C style source files by looking for "#include" without running the compiler, and save the results in a binary database with date stamps so it can run this instantly as needed. Any package dependenciies should be checked with "if" statements in the file, the program would have enough commands to do typical file system things like look for files or grep a file for something, and it is then trivial to write a file that checks for something in multiple places by using "if-else" statements.
Okay I am now officially old. I was in high school when Star Wars came out.
There was no advance publicity. We lived in the suburbs of Boston, and it was one of the first cities Star Wars was released in.
My family had gotten into watching the reruns of Star Trek on the UHF stations, and I believe by this time had seen most of the episodes and were just turning it on each day to see if either an episode we had not seen, or a "good" episode was on.
The first thing I heard about Star Wars was my Dad saying "there seems to be some rip off of Star Trek in the theatres". He had seen an ad for the movie on TV. Somewhat later I saw the same ad. My first impression was it had to be a British production, done by the Andersons of Thunderbirds and Space 1999 fame, as it certainly looked that style. Despite the fact that American Grafitti was a HUGE hit just a few years earlier and we had all gone to see it, there was no indication of a connection with the director. As I remember it, American Grafitti had just as much impact on popular culture as Jaws.
There was then an absolutley positive review in the Boston Globe for the film. Quotes I remember is that "the robots have more personality than the leads in many films" and the spectacular special effects. That convinced me that I really wanted to see the film. But I did not do much else about that.
It seems that maybe a week later that the public perception and the news reports started indicating that this was an enormous hit of unprecedented proportions. Absolutely there was talk *everywhere* about Star Wars. Though initially only a few people had seen it. The ones I knew said it was "good", though there seemed to be an envious feeling between the "seen it" and "had not seen it" people.
Finally in mid-week my Dad got everybody in the car and we drove to Boston to see it in the big 70mm theatre. Well it turned out that even then, perhaps 2.5 weeks after opening, it was impossible to get in. We instead drove around darkened Boston and looked at the LNG tanker that was tied up there (these were also a big deal, what happened to them?)
I later saw it in midday, perhaps 4 weeks after opening, by then you could buy a ticket for midday and get in. It was fun, and funny, and I was constantly aware that the whole thing seemed to be a spoof or a homage to other adventure films, especially the over-the-top violent bar where nobody thinks much of anybody being killed. Some stuff that seems obvious I missed, for instance I did not identify the big sphere as the "death star" from the title crawl. I also thought the movie was ending when they escaped the death star and was suprised by the battle at the end. Still thinking it was an Anderson production I predicted that they would blow a great deal of stuff up, I did not identify the homage to the WWII fighter movies that the battle actually was. Besides humor and adventure, Star Wars also seemed to deliver a believable universe, and that sand planet seemed to really exist, be planet-sized, and be part of a universe of thousands of such planets, and Luke really did seem to be a tiny figure and the Empire an unstoppable power. No sequel since has been able to be so believable.
Like most good geeks I saw it several times after that, maybe 5. I started to be aware of the audience reactions, such as hissing the villian, something I had never heard in a movie theatre before (or since!)
Star Wars was far bigger than any of the sequels. It was in the news every day, and the fact that it was changing the movie industry forever was obvious and talked about from the first moment!