Unfortunatly such "pixel accuracy" is why they are unable to add antialiasing or hardware acceleration to a lot of X. Programs that depend on such things are broken and prevent improvements to rendering models.
From what I can tell, a basic "composition manager" will be pretty easy to write and will be just part of the Window Manager. This is similar to asking that they work on a standard method of drawing the close button on the windows: totally unnecessary, if they wanted to match it would be easier to copy the code than to cooperate.
Except for Microsoft. For everybody else (the few that are left) OSS is a huge opportunity to sell software again, and get out of the constant fear of Microsoft crushing them by making a bundled replacement, and maybe return to the giddy days of the early 1980's.
Even on Slashdot most people do not belive that OSS will replace commercial software like Quicken or Autocad or Maya, the interior design software, the games, the commercial business-specific software loaded with catalogs of suppliers products. Even word processors are not replaced, sure OSS can write a Word-clone, but Word is stagnent due to lack of competition, if Word was crushed and the stifling need to import and export Word documents eliminated, new word processors may appear that have capabilites nobody has even dreamed of! The free OSS Word-clone you get with your Linux box would be considered a joke in comparison, so would Word.
If Linux (or something like it) is triumphant I think there will be a huge release of amazingly innovative new applications and software. And variations and additions to Linux itself. These will be things that cannot even be imagined by OSS and Microsoft programmers right now, because they will be the inventions of a competitive commercial marketplace and hundreds of thousands of developers (verses the perhaps 10 thousands of Linux developers, and the only thousands of Microsoft developers). This new stuff will make Windows and Longhorn, KDE and Gnome, and even OS/X look like a primitive joke!
If you are a commercial proprietary software company and not tied into supplying Microsoft, you are eagerly awaiting the arrival of Linux!
c) SCO hinted privately at Microsoft (or other firms) involvement.
I'm starting to wonder. It is so obvious that they are doing Microsoft's bidding... is it possible it is not true? Why are investors buying the stock? Surely not for any possible payout from the lawsuit, or any plausable income from Linux. The investors must believe that buying the stock is a way to get some of the big bucks Microsoft is paying SCO! Much better way to get some of their profits than buying Microsoft stock itself!
But some of SCO's recent announcements, where they more and more shrilly say Linux is dangerous and scary and it's problems could not possibly be solved by their lawsuit, and that they will pay you to use Windows, seem to be heavy-handed, exaggerated versions of Microsoft's assummed arguments. There purpose is obviously not to help their case, and lately don't seem really to be attacks on Linux itself (since their arguments cover virtually any software, open or closed, ever written by anybody who read another piece of software). They really seemed to be designed to prove (without saying so) that Microsoft is funding them. Maybe this funding is an entire scam.
Now this will require some inside help at Microsoft, somebody fooled them into making the original purchase of some useless licenses. If such a plot is figured out Microsoft should fire that guy's ass, and perhaps get him thrown in jail. A public action like this is the only way they are going to convince people they did not fund SCO.
So why doesn't Microsoft deny that they are funding it? Because SCO has never literally said they are getting money from Microsoft, so there is nothing to deny. If Microsoft makes a denial without a real accusasion from SCO, then everybody will then say "obviously they are funding it, since they felt they had to deny it".
And don't give me any bullshit about it not working in Emacs. It doesn't work in Emacs on Windows either.
Middle-mouse would be better considered an advanced form of drag & drop, and in fact many programs that support drag & drop work with older programs by faking a middle-mouse click when you drop on them.
Both Gnome and KDE use freetype/Xft to render fonts, so there is no difference between them there.
Gnome's biggest problem is that the goofballs who are writing it just can't stand to see 1000 bytes of replicated code. As soon as a function is used by more than one program (even if one of them is in developement and won't be available for years) they go "oh no we need a shared library!". They do this before they even debug the function, so instead you have a whole string of shared library versions and you always need the correct one. This mentality is why Gnome consists of literally hundreds of shared libraries and that you always have to download every single one of them with any program. Wake up guys: cut and paste the code and static link, it is not an affront to the programming Gods, it is a sensible and practical way to develop usable software! And practically speaking, the overhead of shared libraries way outweighs any plausable savings by sharing some functions. If they are really in such a panic over this, it would be better to have Linux hash-code read-only pages and share identical ones, so when you static-link a library into several programs, Linux may notice the matching pages and save your precious 10 or 20 K.
If you "trusted the consumer" then you would "trust" them not to pirate the disk. By definition DRM means they don't "trust the consumer".
Get it? This has nothing to do with wether or not the consumer really should be trusted. Maybe everybody immediatly uploads every CD they buy to KAzaa and the companies are perfectly right not to trust them. But the joke is that they claim they "trust" the consumer but their actions show that they believe otherwise.
Get it now? It's unbelievable how stupid some of the posters here are...
Also the moon blocks debris from more than 50% of the possible directions it can come from.
However a huge problem with putting the collectors on the moon is that they will be in the dark for 50% of the time, in 15-day intervals. Something in geo-synchronous orbit would only be in the dark for about 1% of the time and once a day and only during 2 short segments of the year.
I would think you need to build two collectors, each at the just-visible area edge of the moon, so one is in sunlight all the time. Or if it is possible to use cables then three or more, equally spaced around the moon, with cables leading to the microwave transmitter on the near side of the moon.
Disney has been using computers to paint and composite since the Rescuers Down Under (Beauty and the Beast was the first 100% digital production). So this is not a decision to start using computers.
From what I have heard, they literally think that people are refusing to see films that don't look 3-D, and that all future productions are to look like Shreck.
Hey, that's exactly what is needed. However I am still frustrated by the fact that the people working on gnome-vfs and konqueror are not using this, and instead requiring use of their own library, and that this is not part of Linux 2.6 already. We need "cat" and every other program running on Linux to be able to read any file anything wants to serve, such as http and ftp and every field in every file in/etc (similar to MicroSoft's registry fix) and probably a million other things nobody has thought of yet (in fact I expect OSS to be vastly superior to MicroSoft at thinking of ways to present stuff as files and this *could* be the "killer app").
Read up on Plan9 (plan9.att.com ?) and you will see that this is NOT a new or innovative idea. However it is good to see somebody starting to "get" the "everything is a file" idea.
Linux NEEDS to do something NOW so user-level programs can serve files, and programs can read/write them using the NORMAL open()/close() calls in libc (not use gnome-vfs or anything like this). I consider the vital and is extremely frustrating that nobody seems to be working on this. So instead we see Microsoft doing a typical stupid job of one thing at a time (like the registry) but at least gradually stumbling in the right direction, while Linux just sits there, frozen by absolute paranoia about being incompatable with POSIX...
Don't forget NeWS, which was before DPS, and probably better designed.
Basically Microsoft (and Linux) are just now catching up with rendering models designed 18 years ago! And both of them are going to have the gall to call this "innovation".
Slashdot probably deleted a post. I was not responding to the original poster, but to somebody who thought things would be better if the "root uid" was not a constant but was a variable.
The original poster does have a point, "backwards ==" like he uses would make it harder to accidentally do this, though I'm unsure if it would stop a malicious insertion like this unless every single kernel developer used backwareds ==.
No that would not help one bit. The code is designed to look like you are testing to see if current->uid is equal to the root uid. I doubt putting the root id in a variable, or using a macro/enum/constant like ROOT_ID would make the slightest difference in the ability to catch this.
Please tell me any plausable reason why the mistake is easier to see in the second case than the first:
Contrary to popular belief, "ray tracing" is actually a very efficient way to render images when there are a small (ie dozens) number of surfaces and there is no reflection of rays or any kind of lighting. This lends itself especially well to hardware that does the composite, as it only has to think about one pixel at a time, and you don't have to store a Z or alpha buffer in the final image.
So I am not suprised this works.
Unfortunatly "no font support" indicates the problem: for any real display each letter is going to be several polygons and thus the number of objects goes suddenly from dozens to hundreds of thousands. You will have to render all the text into a bitmap to get reasonable speed (this is the solution OS/X and Longhorn and probably X will use), or go to a per-object accumulation rendering like all 3D cards use.
That's the way it is supposed to work. That is not the "xterm middle-click paste buffer", that is the "selection buffer" and all programs are expected to update it when you change selections.
Try clicking the middle mouse button in almost any other program (for instance in xterm) after you select the URL and you will see, I hope...
X does have backing store. I have programed quite a bit in this.
Even the first X servers had Pixmap objects. You can draw into these and copy them to the screen. Because the reside on the server, a correct implementation can do it vastly faster than a local copy maintained by the program. In fact it is obvious that X pixmaps are vastly faster than Windows Bitmap objects, which I am forced to use on Windows to get backing-store on windows right now.
Even the first people to use X realized that Pixmaps could be used for backing store, and this led to the problem that programs immediatly allocated quite a few pixmaps for this and on early X servers exausted the memory. I think this caused a lot of people to say "don't do that!" and probably is why people now seem to think X does not have this. However on modern X servers I have seen no problem making every window in my program have a Pixmap backing store. The resulting pixmaps are equal to 10 to 20 screens in size.
There is also the Xdbe double-buffer extension. This works like OpenGL double-buffering. In this case there is only an offscreen pixel for each visible pixel on the screen, so the memory usage is fixed to the screen size, and also time is not wasted updating invisible windows (a possibly serious problem with the OS/X and Longhorn and these new X ideas that I don't think people are worried enough about!) On older hardware such double-buffering was the only way to get hardware acceleration. Xdbe does suffer from a typical horrid cryptic X API and seems to produce black blinking on my Nvidea driver when resizing windows. Double buffering also has the problem that the "compositing" now popular cannot be done, as only one window can contribute to each final pixel.
Backing store of various forms has been around for a LONG time, incidentally. However except for the "game sprites" popular on hardware on the 70's, the "composite on the fly" implementation that everybody is thinking about now did not exist. It is unfortunatle that everybody now seems to think the only purpose of backing store is to make transparent windows. Backing store has many other much more important purposes than that.
They will be rendering the window system and applying it as a texture so that the DPI of the monitor is irrelevant
This is not true. If the texture is made of pixels (and not a display list) then it is extremely important that the texture be made at the same resolution it will be displayed on the screen, or some integer multiple (up to about 10 or so, at which point it probably does not matter if it is an integer multiple or not).
You are probably confusing the texture mapping with the new floating-point drawing interface. The drawing interface is what makes it easier for a program to scale and still produce nice output. However the output would be equally nice even if the system was otherwise like present-day Windows or X and drew directly into the framebuffer.
Texture-mapping does not help the quality of the display and could hurt by making it too easy to accidentally get multiple resizes of images and fonts before the display.
Those other systems have a single "compositing engine". On OS/X this appears to be an OpenGL object that is texture-mapped and the results Z + alpha composited to get the screen display.
What he is proposing is to allow the compositing engine itself to be specified by different programs, in particular by the window manager. Now the primary reason I can see for this is that older X apps create literally hundreds of windows, and it is necessary to have a fast default, which is not going to be the desired engine for a Quartz-like window manager. Therefore there has to be at least two compositing engines, and once you have two you might as well allow an unlimited number of them.
Now obviously X has no compositing engine right now (or really one, but it destructively composites into the parent window's source), and the difference between 0 and 1 compositing engine is much more than the difference between 1 and many. However this is still a very clever idea and is NOT something that exists already!
Don't forget NeWS, which did the PostScript GUI much better (everything was done with postscript, while DPS uses other calls to create windows and manage events). NeWS was also out much earlier and was enormously easier to modify the toolkit on as it was all in PostScript.
Slashdot Mirror
Unfortunatly such "pixel accuracy" is why they are unable to add antialiasing or hardware acceleration to a lot of X. Programs that depend on such things are broken and prevent improvements to rendering models.
From what I can tell, a basic "composition manager" will be pretty easy to write and will be just part of the Window Manager. This is similar to asking that they work on a standard method of drawing the close button on the windows: totally unnecessary, if they wanted to match it would be easier to copy the code than to cooperate.
Even on Slashdot most people do not belive that OSS will replace commercial software like Quicken or Autocad or Maya, the interior design software, the games, the commercial business-specific software loaded with catalogs of suppliers products. Even word processors are not replaced, sure OSS can write a Word-clone, but Word is stagnent due to lack of competition, if Word was crushed and the stifling need to import and export Word documents eliminated, new word processors may appear that have capabilites nobody has even dreamed of! The free OSS Word-clone you get with your Linux box would be considered a joke in comparison, so would Word.
If Linux (or something like it) is triumphant I think there will be a huge release of amazingly innovative new applications and software. And variations and additions to Linux itself. These will be things that cannot even be imagined by OSS and Microsoft programmers right now, because they will be the inventions of a competitive commercial marketplace and hundreds of thousands of developers (verses the perhaps 10 thousands of Linux developers, and the only thousands of Microsoft developers). This new stuff will make Windows and Longhorn, KDE and Gnome, and even OS/X look like a primitive joke!
If you are a commercial proprietary software company and not tied into supplying Microsoft, you are eagerly awaiting the arrival of Linux!
I'm starting to wonder. It is so obvious that they are doing Microsoft's bidding... is it possible it is not true? Why are investors buying the stock? Surely not for any possible payout from the lawsuit, or any plausable income from Linux. The investors must believe that buying the stock is a way to get some of the big bucks Microsoft is paying SCO! Much better way to get some of their profits than buying Microsoft stock itself!
But some of SCO's recent announcements, where they more and more shrilly say Linux is dangerous and scary and it's problems could not possibly be solved by their lawsuit, and that they will pay you to use Windows, seem to be heavy-handed, exaggerated versions of Microsoft's assummed arguments. There purpose is obviously not to help their case, and lately don't seem really to be attacks on Linux itself (since their arguments cover virtually any software, open or closed, ever written by anybody who read another piece of software). They really seemed to be designed to prove (without saying so) that Microsoft is funding them. Maybe this funding is an entire scam.
Now this will require some inside help at Microsoft, somebody fooled them into making the original purchase of some useless licenses. If such a plot is figured out Microsoft should fire that guy's ass, and perhaps get him thrown in jail. A public action like this is the only way they are going to convince people they did not fund SCO.
So why doesn't Microsoft deny that they are funding it? Because SCO has never literally said they are getting money from Microsoft, so there is nothing to deny. If Microsoft makes a denial without a real accusasion from SCO, then everybody will then say "obviously they are funding it, since they felt they had to deny it".
Type Ctrl+X to cut, and Ctrl+V to paste.
And don't give me any bullshit about it not working in Emacs. It doesn't work in Emacs on Windows either.
Middle-mouse would be better considered an advanced form of drag & drop, and in fact many programs that support drag & drop work with older programs by faking a middle-mouse click when you drop on them.
Both Gnome and KDE use freetype/Xft to render fonts, so there is no difference between them there.
Gnome's biggest problem is that the goofballs who are writing it just can't stand to see 1000 bytes of replicated code. As soon as a function is used by more than one program (even if one of them is in developement and won't be available for years) they go "oh no we need a shared library!". They do this before they even debug the function, so instead you have a whole string of shared library versions and you always need the correct one. This mentality is why Gnome consists of literally hundreds of shared libraries and that you always have to download every single one of them with any program. Wake up guys: cut and paste the code and static link, it is not an affront to the programming Gods, it is a sensible and practical way to develop usable software! And practically speaking, the overhead of shared libraries way outweighs any plausable savings by sharing some functions. If they are really in such a panic over this, it would be better to have Linux hash-code read-only pages and share identical ones, so when you static-link a library into several programs, Linux may notice the matching pages and save your precious 10 or 20 K.
If you "trusted the consumer" then you would "trust" them not to pirate the disk. By definition DRM means they don't "trust the consumer".
Get it? This has nothing to do with wether or not the consumer really should be trusted. Maybe everybody immediatly uploads every CD they buy to KAzaa and the companies are perfectly right not to trust them. But the joke is that they claim they "trust" the consumer but their actions show that they believe otherwise.
Get it now? It's unbelievable how stupid some of the posters here are...
The GPL is "copyright-based" as well, you know.
The similarity is a hatred of organizations that control of the dissemination of information.
Also the moon blocks debris from more than 50% of the possible directions it can come from.
However a huge problem with putting the collectors on the moon is that they will be in the dark for 50% of the time, in 15-day intervals. Something in geo-synchronous orbit would only be in the dark for about 1% of the time and once a day and only during 2 short segments of the year.
I would think you need to build two collectors, each at the just-visible area edge of the moon, so one is in sunlight all the time. Or if it is possible to use cables then three or more, equally spaced around the moon, with cables leading to the microwave transmitter on the near side of the moon.
Disney has been using computers to paint and composite since the Rescuers Down Under (Beauty and the Beast was the first 100% digital production). So this is not a decision to start using computers.
From what I have heard, they literally think that people are refusing to see films that don't look 3-D, and that all future productions are to look like Shreck.
You are confusing Capitalism with Anarchy. They are different.
Hey, that's exactly what is needed. However I am still frustrated by the fact that the people working on gnome-vfs and konqueror are not using this, and instead requiring use of their own library, and that this is not part of Linux 2.6 already. We need "cat" and every other program running on Linux to be able to read any file anything wants to serve, such as http and ftp and every field in every file in /etc (similar to MicroSoft's registry fix) and probably a million other things nobody has thought of yet (in fact I expect OSS to be vastly superior to MicroSoft at thinking of ways to present stuff as files and this *could* be the "killer app").
Read up on Plan9 (plan9.att.com ?) and you will see that this is NOT a new or innovative idea. However it is good to see somebody starting to "get" the "everything is a file" idea.
Linux NEEDS to do something NOW so user-level programs can serve files, and programs can read/write them using the NORMAL open()/close() calls in libc (not use gnome-vfs or anything like this). I consider the vital and is extremely frustrating that nobody seems to be working on this. So instead we see Microsoft doing a typical stupid job of one thing at a time (like the registry) but at least gradually stumbling in the right direction, while Linux just sits there, frozen by absolute paranoia about being incompatable with POSIX...
Don't forget NeWS, which was before DPS, and probably better designed.
Basically Microsoft (and Linux) are just now catching up with rendering models designed 18 years ago! And both of them are going to have the gall to call this "innovation".
Slashdot probably deleted a post. I was not responding to the original poster, but to somebody who thought things would be better if the "root uid" was not a constant but was a variable.
The original poster does have a point, "backwards ==" like he uses would make it harder to accidentally do this, though I'm unsure if it would stop a malicious insertion like this unless every single kernel developer used backwareds ==.
No that would not help one bit. The code is designed to look like you are testing to see if current->uid is equal to the root uid. I doubt putting the root id in a variable, or using a macro/enum/constant like ROOT_ID would make the slightest difference in the ability to catch this.
Please tell me any plausable reason why the mistake is easier to see in the second case than the first:
if (foo = 0) {...}
if (foo = x) {...}
Both Visual C and GCC will not produce the warning if there are parenthesis around the assignement statement, as there are here.
Well of course, that is the entire reason everybody here is saying there should be a piece of paper.
I strongly recommend that random precients be manually counted and compared to the machine tallies there, even if the contest is not disputed.
Contrary to popular belief, "ray tracing" is actually a very efficient way to render images when there are a small (ie dozens) number of surfaces and there is no reflection of rays or any kind of lighting. This lends itself especially well to hardware that does the composite, as it only has to think about one pixel at a time, and you don't have to store a Z or alpha buffer in the final image.
So I am not suprised this works.
Unfortunatly "no font support" indicates the problem: for any real display each letter is going to be several polygons and thus the number of objects goes suddenly from dozens to hundreds of thousands. You will have to render all the text into a bitmap to get reasonable speed (this is the solution OS/X and Longhorn and probably X will use), or go to a per-object accumulation rendering like all 3D cards use.
He is talking about compositing server-side images.
We can already composite client-side images all we want! In fact we can do that without any X calls at all. How about that?
That's the way it is supposed to work. That is not the "xterm middle-click paste buffer", that is the "selection buffer" and all programs are expected to update it when you change selections.
Try clicking the middle mouse button in almost any other program (for instance in xterm) after you select the URL and you will see, I hope...
X does have backing store. I have programed quite a bit in this.
Even the first X servers had Pixmap objects. You can draw into these and copy them to the screen. Because the reside on the server, a correct implementation can do it vastly faster than a local copy maintained by the program. In fact it is obvious that X pixmaps are vastly faster than Windows Bitmap objects, which I am forced to use on Windows to get backing-store on windows right now.
Even the first people to use X realized that Pixmaps could be used for backing store, and this led to the problem that programs immediatly allocated quite a few pixmaps for this and on early X servers exausted the memory. I think this caused a lot of people to say "don't do that!" and probably is why people now seem to think X does not have this. However on modern X servers I have seen no problem making every window in my program have a Pixmap backing store. The resulting pixmaps are equal to 10 to 20 screens in size.
There is also the Xdbe double-buffer extension. This works like OpenGL double-buffering. In this case there is only an offscreen pixel for each visible pixel on the screen, so the memory usage is fixed to the screen size, and also time is not wasted updating invisible windows (a possibly serious problem with the OS/X and Longhorn and these new X ideas that I don't think people are worried enough about!) On older hardware such double-buffering was the only way to get hardware acceleration. Xdbe does suffer from a typical horrid cryptic X API and seems to produce black blinking on my Nvidea driver when resizing windows. Double buffering also has the problem that the "compositing" now popular cannot be done, as only one window can contribute to each final pixel.
Backing store of various forms has been around for a LONG time, incidentally. However except for the "game sprites" popular on hardware on the 70's, the "composite on the fly" implementation that everybody is thinking about now did not exist. It is unfortunatle that everybody now seems to think the only purpose of backing store is to make transparent windows. Backing store has many other much more important purposes than that.
This is not true. If the texture is made of pixels (and not a display list) then it is extremely important that the texture be made at the same resolution it will be displayed on the screen, or some integer multiple (up to about 10 or so, at which point it probably does not matter if it is an integer multiple or not).
You are probably confusing the texture mapping with the new floating-point drawing interface. The drawing interface is what makes it easier for a program to scale and still produce nice output. However the output would be equally nice even if the system was otherwise like present-day Windows or X and drew directly into the framebuffer.
Texture-mapping does not help the quality of the display and could hurt by making it too easy to accidentally get multiple resizes of images and fonts before the display.
Those other systems have a single "compositing engine". On OS/X this appears to be an OpenGL object that is texture-mapped and the results Z + alpha composited to get the screen display.
What he is proposing is to allow the compositing engine itself to be specified by different programs, in particular by the window manager. Now the primary reason I can see for this is that older X apps create literally hundreds of windows, and it is necessary to have a fast default, which is not going to be the desired engine for a Quartz-like window manager. Therefore there has to be at least two compositing engines, and once you have two you might as well allow an unlimited number of them.
Now obviously X has no compositing engine right now (or really one, but it destructively composites into the parent window's source), and the difference between 0 and 1 compositing engine is much more than the difference between 1 and many. However this is still a very clever idea and is NOT something that exists already!
Don't forget NeWS, which did the PostScript GUI much better (everything was done with postscript, while DPS uses other calls to create windows and manage events). NeWS was also out much earlier and was enormously easier to modify the toolkit on as it was all in PostScript.