That can't possibly be true, as BSD code can be incorporated into GPL code. Since this code cannot be incorporated into GPL code, it can't be incorporated into BSD code either.
I think you are thinking of it the other way, that you could take BSD code and link it with this and the result is not BSD but their license. But that is not BSD compatible unless you want to claim the GPL is also BSD compatible, and I don't think anybody says that.
Maybe it's older than that, but if you watched TV when you were a child, you would know that "MS" MEANS "Multiple Sclerosis". There was literally an ad for the MS Society every half hour.
In my opinion you should NOT use "MS". The best is "Microsoft" but "M$" is acceptable if you really feel a need to make the text short. I do believe "MS" is unreadable because of Multiple Sclerosis, believe me I READ IT EXACTLY THAT WAY!!!!
"MSoft" is bad. I also don't like "MSFT", as I think the use of the stock symbol is equal to the dollar sign, while also being much harder to read and may also be confusing as it looks like the abbreviation of a Microsoft product.
I do find it humourous that you guys all go crazy about "M$". Calling it "Microsucks" or other obvious childish things never got a comment. Apparently you are very threatened by the popularity of "M$" and are desparate to try to make people think it is "immature".
I'm going to have to make a point of putting M$ in any posts I do from now on. This is just too funny.
This is really getting tiring. Saying "M$" does not reduce a post's credibility, it makes it a huge amount easier to read as I read it as "Microsoft" rather than "Multiple Sclerosis". Anybody who thinks "MS" is a good idea is obviously under 30. That letter was hard to read. If you want to avoid "M$" you should spell out "Microsoft" (and as I learned you don't capitalize the 's' or apparently that is an enormous insult as well...)
In any case, you can keep whining all you want but in the end you are the one who looks childish. Sorry, but "M$" is pretty well established. There is nothing that short that works better.
Go ahead and write O$$ if you think that will even things out. I don't think anybody will care.
Though I do little Windows programming, I do want to back up the above about GDI+, which was an incredible waste of time and effort on my part. I thought just a little bit of rewriting of fltk and we would get antialiasing lines and polygons and filtered arbitrary image transforms, just like it looked like you could get with Quartz on OSX and the (still rather rudimentary) Cairo on Linux. Though writing a cross-platform API I was very interesting in locating the common functions between these, and in the case of Cairo, trying to encourage them to not be incompatable with GDI+ for no good reason as I (mistakenly) assumed it would have huge influence (mostly I want them to remove the effect of changing the CTM on an already-selected pen or font).
It was incredibly frustrating to discover after a good deal of research and attempts to compile it that it was never going to work unless you had the right driver (ie it was an *option*) and that code was expected to support the old api as well. And then to find out that Silverlight had nothing to do with it. Currently we are getting better graphics on X (with XRender) than on Windows (ie images filter when resized) and on no platforms are we using the more modern api, and all the blame can be put on the mistaken impression that Microsoft was going to deliver what I expected in GDI+.
"disintegrating screen" That's the modern logo for Windows, not Microsoft.
Actually I don't think Microsoft has any logo, except for the word "Microsoft" in a particular font.
Personally I like the borg icon, it is funny. Slashdot should ditch that stupid broken-window one and use the real Windows logo, however. There is a difference between a real humourous explanation of why something is disliked (the borg icon) and just randomly insulting something with no analysis (the broken window).
I agree this would wipe out Linux, provided it is "open" in such a way that popular changes can be added to the "main distribution". What will then happen is full Unix compatibility, by default, will be added to the kernel, probably so fast it will make Ballmer's head spin, such as within weeks.
Unix compatibility, not "freedom" and/or "stick it to Microsoft", is the real reason Linux is popular. This change will delete Linux's advantage. After that I think Linux is doomed, except it is possible that the easiest way to fix Windows would be to replace the kernel with Linux. Still the user space stuff (KDE/Gnome/X) is going to be abandoned. Some Linux ideas will probably be saved (/proc, fuse, some of the file systems). One Unix thing that is sure to disappear is mounting as an application, the drivers will be able to cause their device to appear in the filename space themselves.
Yea, multitasking was a great idea in its day but now with multi-core CPUs and excellent VMs (VMWare, VirtualBox, etc.) why do those OS designers keep doing it? You could just run every program in it's own virtual machine!
Of course this dates back to when there was the BSD advertising clause, so it was not legally possible to copy the code to GPL. Thus the CDDL would not have stopped this from happening either. However the modern BSD does not have the advertising clause and thus can be converted into a GPL project. Still waiting for you to name an example where such a GPL version exists and contains useful functional additions over the BSD version.
The problem with your premise is that anybody who did this would be blasted with negative publicity and thus their code would never be accepted.
Bison was written primarily by Robert Corbett; Richard Stallman made it Yacc-compatible. Wilfred Hansen of Carnegie Mellon University added multi-character string literals and other features.
I will indeed say: well, they could stipulate that all submissions have to be dual-licensed.
You appear to have discovered the answer to all your problems while you were typing your response. That is exactly what they could do. You then came up with this weird and rather convoluted excuse as to why that very simple solution would not work:
you and I both know we'd see some stupid little gnuZFS the same day as ZFS was GPL'd, just to get around that.
Do you have ANY examples of this happening, ever? Please name the project where such a fork survived in any useable form.
The problem is that the window manager resizes the window, but a different program (the application) receives a message that the window resized and then responds by redrawing it's contents. The window manager cannot wait for this to happen as that application may be blocked or crashed, and besides X has no such synchronization mechanism anyway.
On Windows a resize draws the border, but then sends a "paint" event directly to the application. This allows it to wait until that "paint" event returns, and thus it can cleanly surround the entire resize + paint border + paint contents with the necessary locking to make smooth resizes. This has nothing to do with speed or anything else.
I think the proper solution is to just have the program do the entire window. Ie it actually detects that the user clicks in the edge, tracks the mouse, and resizes the window, and paints both the border and contents. This makes it work at least as well as Windows, while also being much simpler.
It also allows the programs to all have different borders, which for some reason makes some of the UI fanatics crazy with worry and is really the reason this has not been done. This is despite the fact that the interiors have been allowed to differ always, and it is solved there easily: people use toolkits, and "bad" programs drop out of favor.
Certainly it is possible that Microsoft plans to Embrace&Extend ODF. However if this is there plan, they still wasted all that time and money and karma on the bribery of the standards committees for MSOOXML. If they had just said "Word will support ODF" initially they could have started on their embrace&extend a year or more ago, and been much further along, and under a lot less scrutiny, than they are now.
You do have an interesting explanation as to why they would change strategies at the last moment (France basically requiring that OOXML be open). But I was under the impression that OOXML's primary purpose was that it was trivial for Word to write it, while difficult for everybody else, and making it an open standard would not change that.
I think they made a serious mistake. I believe they will still absolutely control the word processing market even if they only read and wrote standard ODF, and I think some engineers there tried to point that out. It is also possible that OOXML is screwed up and not as simple of a dump of Word as they thought, perhaps it is messed up so bad that it is actually easier to write ODF. It is also possible that some engineers revolted and refused to work on OOXML.
It certainly is a mystery why Microsoft would spend all the money and accept all the bad publicity with their effort to bribe everyone in the world to mark MSWordXML as a standard, and then just drop it right after they "won". With one press release they have killed their format dead, and thus they have cancelled every bit of the bribes, FUD, and the expense of a chunk of their remaining karma, so that they have lost everything.
Why the hell do all that work to end up in exactly same position they would be if they had just accepted ODF?
I don't think it's possible this is some nefarious complex scheme by Microsoft. It seems to indicate that this giant organization is losing control of itself. Somehow the FUD & bribery machine was started up, and probably immediately some engineers there started saying "whoa! whoa! It's not necessary!" and they were unable to stop the machine, which has it's own enormous momentum, until millions are spent and the company loses a good chunk of it's remaining karma.
This was probably a troll, but if not, you have it exactly backwards. X is *not* a giant frame buffer, while the alternatives it is being compared to (Remote desktop) *are* giant frame buffers. That does not have anything to do with which is better, but that is their primary differences.
A giant frame buffer may well be better because communicating the changes to the pixels in the buffer may compress much smaller than compressing the X drawing instructions, and (probably more importantly) the drawing is exactly what the program expects, rather than a different machine's interpretation of it.
An offscreen buffer for the contents will not work. The window manager resizes the window, and the application copies the offscreen contents to the window. There is no way for the window manager to force the contents to be copied at the same instant the resize is done. The app cannot wait for the resize as that is too late, and the window will be shown with something other than the resized contents.
Double-buffering would certainly work well if the program drew the borders. Also X would need a fix so that changing the size of the window does not alter any pixels on the screen (ie any pixels that change what window they belong to retain their contents). The buffer swap, even if delayed for quite awhile, will be perfect, as you will either see the old or new window contents always.
Compiz probably helps as there is an offscreen buffer for the entire window, including the border. If we are lucky (and nowadays it is pretty likely) all the resizing and the app and window manager redrawing will all get done before it does another comp to the screen. This is probably why it looks smoother. I think it can still screw up. If in fact the program did the resizing and window border drawing, all the code to resize and draw everything would be packed together and drawn in an exact predictable sequence, if it was possible to wait for the retrace it would always be perfect.
That I admit is annoying. Somehow Windows replicated the one bad aspect of the program doing the windows without ANY of the positive ones (I have tried for years to get a way for it to not raise the window when you click inside it, but either the program is dead or it raises. Despite the fact that this bug could only happen if they passed the window border events to the program before acting on them. They are idiots. At least on Linux you can change the window manager, which is not great, but it is physically possible to get clicks without raise).
I think a timeout would solve this fairly well. For instance Gnome at least has a timeout on the close button, if the program does not respond in a few seconds it offers to kill it. You could timeout clicks, possibly anywhere in the window, if the program does not respond you then drag the window. You know that close was once done by the window manager only, and they had to add an api so the program would do it. I think it would be consistent if they added an api for everything.
It cannot be fixed unless they get rid of the seperate window manager process. Programs should draw their own windows including the border.
The problem is that it is politically incorrect. People will scream that the users will be "confused" by the different window borders, despite the fact that they obviously aren't when Windows, OSX, and even Linux programs such as music players, bypass it. And you can clearly see that those windows run faster.
It would be partially-patchable if the window manager sent some kind of event to the program that said "resize the window to this" and relied on the program doing it so the internal graphics could be synchronized with the resize. The problem is that the border would now blink instead of the interior. Certainly I have suggested this for years and never seen any kind of positive response. I now think any such halfway measure is a waste of time, we should scrap window managers.
Re:Finally, developers' ignorance and childish
on
The State of X.Org
·
· Score: 2, Insightful
You have absolutely no idea what you are talking about.
Here is a small dose of reality: If X had done this, they would have done it in 1985, and the widgets and api would look like Athena. And they would still look like Athena today, with absolutely no change (ignoring the fact that X would have been abandoned long ago). There would have been MILLIONS of assuptions about the design of the widgets that programs would make or would be neglected in the api they designed. It would never have been modifiable in the way your fantasy believes. And don't go thinking that "we know how to do it today". Even five years from now some ideas we have in GUI today will be considered ridiculously incorrect.
The fact is that X lasted for 30 years and can run stuff that was not considered in the least when it was invented is proof that it's design was at the correct level.
Re:Finally, developers' ignorance and childish
on
The State of X.Org
·
· Score: 3, Interesting
You are correct that X wire protocol is ugly. However this is NOT a reason to abandon network transparency. If you removed network transparency you would still have an ugly protocol, just communicated in shared memory instead. But if instead you fixed the protocol while keeping network transparency, you would have the good protocol PLUS network transparency.
The fact that you even remotely consider communicating larger objects than drawing commands to the server, such as widgets, is proof that you have never even thought seriously about how these things are programmed. It will not work, it would be unbelievably complex. In X this is where the horror of the ICCCM window manager hints and protocol come from (basically it is an attempt to put a complex "window+frame" object over the api). Windows and OSX do not do this at all, all communication that leaves the app's local address space is pretty low-level drawing commands.
Client-side fonts are done by sending the bitmaps of the fonts over. It is a huge win, because no longer is there a "font object" that is attempted to be communicated. It is exactly the OPPOSITE of your proposal.
I VERY CLEARLY remember being told in 1969 in elementary school that CO2 would "turn earth into Venus due to the greenhouse effect".
Go ahead and claim otherwise. Maybe both were being told at the same time. Maybe you can accuse me of lying, just like I can accuse you of lying.
I believe a lot of people claiming this are confused by "nuclear winter" which was popularized around 1983. I also pretty clearly remember people arguing against that by saying "everybody knows pollution will make the temperature go up, not down".
Slashdot Mirror
That can't possibly be true, as BSD code can be incorporated into GPL code. Since this code cannot be incorporated into GPL code, it can't be incorporated into BSD code either.
I think you are thinking of it the other way, that you could take BSD code and link it with this and the result is not BSD but their license. But that is not BSD compatible unless you want to claim the GPL is also BSD compatible, and I don't think anybody says that.
Maybe it's older than that, but if you watched TV when you were a child, you would know that "MS" MEANS "Multiple Sclerosis". There was literally an ad for the MS Society every half hour.
In my opinion you should NOT use "MS". The best is "Microsoft" but "M$" is acceptable if you really feel a need to make the text short. I do believe "MS" is unreadable because of Multiple Sclerosis, believe me I READ IT EXACTLY THAT WAY!!!!
"MSoft" is bad. I also don't like "MSFT", as I think the use of the stock symbol is equal to the dollar sign, while also being much harder to read and may also be confusing as it looks like the abbreviation of a Microsoft product.
I do find it humourous that you guys all go crazy about "M$". Calling it "Microsucks" or other obvious childish things never got a comment. Apparently you are very threatened by the popularity of "M$" and are desparate to try to make people think it is "immature".
I'm going to have to make a point of putting M$ in any posts I do from now on. This is just too funny.
This is really getting tiring. Saying "M$" does not reduce a post's credibility, it makes it a huge amount easier to read as I read it as "Microsoft" rather than "Multiple Sclerosis". Anybody who thinks "MS" is a good idea is obviously under 30. That letter was hard to read. If you want to avoid "M$" you should spell out "Microsoft" (and as I learned you don't capitalize the 's' or apparently that is an enormous insult as well...)
In any case, you can keep whining all you want but in the end you are the one who looks childish. Sorry, but "M$" is pretty well established. There is nothing that short that works better.
Go ahead and write O$$ if you think that will even things out. I don't think anybody will care.
Actually the non-commercial clause is incompatible with the BSD license as well.
Yep, they want to make sure everybody thinks "open source" and "non-commercial" are the same thing. Same old Microsoft.
Though I do little Windows programming, I do want to back up the above about GDI+, which was an incredible waste of time and effort on my part. I thought just a little bit of rewriting of fltk and we would get antialiasing lines and polygons and filtered arbitrary image transforms, just like it looked like you could get with Quartz on OSX and the (still rather rudimentary) Cairo on Linux. Though writing a cross-platform API I was very interesting in locating the common functions between these, and in the case of Cairo, trying to encourage them to not be incompatable with GDI+ for no good reason as I (mistakenly) assumed it would have huge influence (mostly I want them to remove the effect of changing the CTM on an already-selected pen or font).
It was incredibly frustrating to discover after a good deal of research and attempts to compile it that it was never going to work unless you had the right driver (ie it was an *option*) and that code was expected to support the old api as well. And then to find out that Silverlight had nothing to do with it. Currently we are getting better graphics on X (with XRender) than on Windows (ie images filter when resized) and on no platforms are we using the more modern api, and all the blame can be put on the mistaken impression that Microsoft was going to deliver what I expected in GDI+.
"disintegrating screen" That's the modern logo for Windows, not Microsoft.
Actually I don't think Microsoft has any logo, except for the word "Microsoft" in a particular font.
Personally I like the borg icon, it is funny. Slashdot should ditch that stupid broken-window one and use the real Windows logo, however. There is a difference between a real humourous explanation of why something is disliked (the borg icon) and just randomly insulting something with no analysis (the broken window).
Please provide links to the posts before I believe you.
You are the deluded one.
According to you that post also equated Microsoft to pigs.
You are not doing a service for Microsoft by making their apologists look so stupid.
I agree this would wipe out Linux, provided it is "open" in such a way that popular changes can be added to the "main distribution". What will then happen is full Unix compatibility, by default, will be added to the kernel, probably so fast it will make Ballmer's head spin, such as within weeks.
Unix compatibility, not "freedom" and/or "stick it to Microsoft", is the real reason Linux is popular. This change will delete Linux's advantage. After that I think Linux is doomed, except it is possible that the easiest way to fix Windows would be to replace the kernel with Linux. Still the user space stuff (KDE/Gnome/X) is going to be abandoned. Some Linux ideas will probably be saved (/proc, fuse, some of the file systems). One Unix thing that is sure to disappear is mounting as an application, the drivers will be able to cause their device to appear in the filename space themselves.
Yea, multitasking was a great idea in its day but now with multi-core CPUs and excellent VMs (VMWare, VirtualBox, etc.) why do those OS designers keep doing it? You could just run every program in it's own virtual machine!
Still it's a rewrite.
Of course this dates back to when there was the BSD advertising clause, so it was not legally possible to copy the code to GPL. Thus the CDDL would not have stopped this from happening either. However the modern BSD does not have the advertising clause and thus can be converted into a GPL project. Still waiting for you to name an example where such a GPL version exists and contains useful functional additions over the BSD version.
The problem with your premise is that anybody who did this would be blasted with negative publicity and thus their code would never be accepted.
BZZZT! Not based on Yacc's source code:
from http://www.gnu.org/software/bison/manual/html_mono/bison.html:
Bison was written primarily by Robert Corbett; Richard Stallman made it Yacc-compatible. Wilfred Hansen of Carnegie Mellon University added multi-character string literals and other features.
Sorry try again.
Name one, please. One where the non-BSD branch actually contains some useful code that is not in the BSD branch.
I will indeed say: well, they could stipulate that all submissions have to be dual-licensed.
You appear to have discovered the answer to all your problems while you were typing your response. That is exactly what they could do. You then came up with this weird and rather convoluted excuse as to why that very simple solution would not work:
you and I both know we'd see some stupid little gnuZFS the same day as ZFS was GPL'd, just to get around that.
Do you have ANY examples of this happening, ever? Please name the project where such a fork survived in any useable form.
I don't believe XDamage helps.
The problem is that the window manager resizes the window, but a different program (the application) receives a message that the window resized and then responds by redrawing it's contents. The window manager cannot wait for this to happen as that application may be blocked or crashed, and besides X has no such synchronization mechanism anyway.
On Windows a resize draws the border, but then sends a "paint" event directly to the application. This allows it to wait until that "paint" event returns, and thus it can cleanly surround the entire resize + paint border + paint contents with the necessary locking to make smooth resizes. This has nothing to do with speed or anything else.
I think the proper solution is to just have the program do the entire window. Ie it actually detects that the user clicks in the edge, tracks the mouse, and resizes the window, and paints both the border and contents. This makes it work at least as well as Windows, while also being much simpler.
It also allows the programs to all have different borders, which for some reason makes some of the UI fanatics crazy with worry and is really the reason this has not been done. This is despite the fact that the interiors have been allowed to differ always, and it is solved there easily: people use toolkits, and "bad" programs drop out of favor.
Certainly it is possible that Microsoft plans to Embrace&Extend ODF. However if this is there plan, they still wasted all that time and money and karma on the bribery of the standards committees for MSOOXML. If they had just said "Word will support ODF" initially they could have started on their embrace&extend a year or more ago, and been much further along, and under a lot less scrutiny, than they are now.
You do have an interesting explanation as to why they would change strategies at the last moment (France basically requiring that OOXML be open). But I was under the impression that OOXML's primary purpose was that it was trivial for Word to write it, while difficult for everybody else, and making it an open standard would not change that.
I think they made a serious mistake. I believe they will still absolutely control the word processing market even if they only read and wrote standard ODF, and I think some engineers there tried to point that out. It is also possible that OOXML is screwed up and not as simple of a dump of Word as they thought, perhaps it is messed up so bad that it is actually easier to write ODF. It is also possible that some engineers revolted and refused to work on OOXML.
It certainly is a mystery why Microsoft would spend all the money and accept all the bad publicity with their effort to bribe everyone in the world to mark MSWordXML as a standard, and then just drop it right after they "won". With one press release they have killed their format dead, and thus they have cancelled every bit of the bribes, FUD, and the expense of a chunk of their remaining karma, so that they have lost everything.
Why the hell do all that work to end up in exactly same position they would be if they had just accepted ODF?
I don't think it's possible this is some nefarious complex scheme by Microsoft. It seems to indicate that this giant organization is losing control of itself. Somehow the FUD & bribery machine was started up, and probably immediately some engineers there started saying "whoa! whoa! It's not necessary!" and they were unable to stop the machine, which has it's own enormous momentum, until millions are spent and the company loses a good chunk of it's remaining karma.
This was probably a troll, but if not, you have it exactly backwards. X is *not* a giant frame buffer, while the alternatives it is being compared to (Remote desktop) *are* giant frame buffers. That does not have anything to do with which is better, but that is their primary differences.
A giant frame buffer may well be better because communicating the changes to the pixels in the buffer may compress much smaller than compressing the X drawing instructions, and (probably more importantly) the drawing is exactly what the program expects, rather than a different machine's interpretation of it.
An offscreen buffer for the contents will not work. The window manager resizes the window, and the application copies the offscreen contents to the window. There is no way for the window manager to force the contents to be copied at the same instant the resize is done. The app cannot wait for the resize as that is too late, and the window will be shown with something other than the resized contents.
Double-buffering would certainly work well if the program drew the borders. Also X would need a fix so that changing the size of the window does not alter any pixels on the screen (ie any pixels that change what window they belong to retain their contents). The buffer swap, even if delayed for quite awhile, will be perfect, as you will either see the old or new window contents always.
Compiz probably helps as there is an offscreen buffer for the entire window, including the border. If we are lucky (and nowadays it is pretty likely) all the resizing and the app and window manager redrawing will all get done before it does another comp to the screen. This is probably why it looks smoother. I think it can still screw up. If in fact the program did the resizing and window border drawing, all the code to resize and draw everything would be packed together and drawn in an exact predictable sequence, if it was possible to wait for the retrace it would always be perfect.
That I admit is annoying. Somehow Windows replicated the one bad aspect of the program doing the windows without ANY of the positive ones (I have tried for years to get a way for it to not raise the window when you click inside it, but either the program is dead or it raises. Despite the fact that this bug could only happen if they passed the window border events to the program before acting on them. They are idiots. At least on Linux you can change the window manager, which is not great, but it is physically possible to get clicks without raise).
I think a timeout would solve this fairly well. For instance Gnome at least has a timeout on the close button, if the program does not respond in a few seconds it offers to kill it. You could timeout clicks, possibly anywhere in the window, if the program does not respond you then drag the window. You know that close was once done by the window manager only, and they had to add an api so the program would do it. I think it would be consistent if they added an api for everything.
It cannot be fixed unless they get rid of the seperate window manager process. Programs should draw their own windows including the border.
The problem is that it is politically incorrect. People will scream that the users will be "confused" by the different window borders, despite the fact that they obviously aren't when Windows, OSX, and even Linux programs such as music players, bypass it. And you can clearly see that those windows run faster.
It would be partially-patchable if the window manager sent some kind of event to the program that said "resize the window to this" and relied on the program doing it so the internal graphics could be synchronized with the resize. The problem is that the border would now blink instead of the interior. Certainly I have suggested this for years and never seen any kind of positive response. I now think any such halfway measure is a waste of time, we should scrap window managers.
You have absolutely no idea what you are talking about.
Here is a small dose of reality: If X had done this, they would have done it in 1985, and the widgets and api would look like Athena. And they would still look like Athena today, with absolutely no change (ignoring the fact that X would have been abandoned long ago). There would have been MILLIONS of assuptions about the design of the widgets that programs would make or would be neglected in the api they designed. It would never have been modifiable in the way your fantasy believes. And don't go thinking that "we know how to do it today". Even five years from now some ideas we have in GUI today will be considered ridiculously incorrect.
The fact is that X lasted for 30 years and can run stuff that was not considered in the least when it was invented is proof that it's design was at the correct level.
You are correct that X wire protocol is ugly. However this is NOT a reason to abandon network transparency. If you removed network transparency you would still have an ugly protocol, just communicated in shared memory instead. But if instead you fixed the protocol while keeping network transparency, you would have the good protocol PLUS network transparency.
The fact that you even remotely consider communicating larger objects than drawing commands to the server, such as widgets, is proof that you have never even thought seriously about how these things are programmed. It will not work, it would be unbelievably complex. In X this is where the horror of the ICCCM window manager hints and protocol come from (basically it is an attempt to put a complex "window+frame" object over the api). Windows and OSX do not do this at all, all communication that leaves the app's local address space is pretty low-level drawing commands.
Client-side fonts are done by sending the bitmaps of the fonts over. It is a huge win, because no longer is there a "font object" that is attempted to be communicated. It is exactly the OPPOSITE of your proposal.
This is totally contrary to what I remember.
I VERY CLEARLY remember being told in 1969 in elementary school that CO2 would "turn earth into Venus due to the greenhouse effect".
Go ahead and claim otherwise. Maybe both were being told at the same time. Maybe you can accuse me of lying, just like I can accuse you of lying.
I believe a lot of people claiming this are confused by "nuclear winter" which was popularized around 1983. I also pretty clearly remember people arguing against that by saying "everybody knows pollution will make the temperature go up, not down".