Hmmm. Can't help but wonder if 'Foogle' might not have already done this with 'Foogle.' After all, what better way to flame freely, than to take 'Foogle.'. Since everybody knows that the groupies try to troll as someone by registering their nick with a period after it, which he reinforces by posting immediately after 'Foogle.'s comments "That wasn't me" signed 'Foogle', maybe he is 'Foogle.'.
That would be pretty sad though. Being one's own groupie, I mean. Then again, what about Hemos?
He was referring to Quartz to the extent that he could reproduce its ability to accomplish Aqua's look, including arbitrary transformations of screen elements, as I said.
This does NOT include true vectorization of complete interface elements, nor the ability for some degree of intelligence to reside in the display server by its use of Postscript ala NeWS, etc.
So I stand by my statement - We're talking about Aqua's look, not the full vectorization. Actually, Quartz throws out functionality. If an earlier poster was correct, PDF is NOT a strict superset of Postscript - the prior poster's claim was that PDF drops Turing-completeness. If so, then Quartz is dropping much of the power of NeWS, which is sad.
I favor Berlin, primarily because they seem to be trying for many of the goals of NeWS; specifically, the goal of the separation between the server and client being app-dependent.
Many of the complaints about X have to do with its network protocol; more specifically, the level at which it operates. Different applications work best at different levels of network abstraction. Berlin's design, based on Corba components, which can be either in the server or the client, allows each application to control which level of abstraction becomes the network layer. Thus, network traffic, even going through the overhead of the Corba protocol, can be minimized, because it may only take one Corba packet where X sends twenty.
But I'm moving off track - again, I'll state it - libart is NOT vector based - it is transformation based. It applies an arbitrary transformation matrix to a bitmapped image. This is not the same as using Postscript (which I have hand-written programs in --- not reports, not texts, PROGRAMS). Postscript is a Turing complete language with a rich graphics library built-in. IF PDF is not Turing-complete, that reduces the potential functionality of Quartz, but may enhance it in reality, since it means the interpreter and display paths can be more optimized. That has ever been the Mac Mantra, to sacrifice flexibility for ease, whether of implementation or use.
Libart provides optimized, fast, anti-aliased transformations of bitmapped images. (Note, my understanding of libart is largely from reading documents on GNOME website and Enlightenment website talking about imlib1 and imlib2, and why Gnome is moving away from imlib, etc. My understanding could be flawed.)
Actually, the concept of a vector based GUI is not new, considering they 'copied' it from NeXT (really cool stuff for its time), but irrespective of that, an Open-Source project to provide a vector-based alternative to X has been in progress for some time.
It currently suffers from the ESR RampUp syndrome - i.e. the necessity to have a minimally working product before the OS scale-up really begins to have an impact.
They are basing it on OpenGL and GGI. Its called 'Berlin'. They've got a page at SourceForge.
Nothing actually usable in terms of replacing X yet though.
Then there's always the GNUStep people... I think they're trying to use 'Display Ghostscript'.
All things considered, I don't think Quartz is a really monumental achievement. After all, they had NeXT's implementation of Display Postscript to work from. Considering how quickly gv was adapted to display PDF files, I don't think there was too much work involved in upping 'Display Postscript' to 'Display PDF'. And I think the dropping of the license fee from Postscript to PDF was probably the driving factor, moreso than the technical issues mentioned.
As for the ability to reference previously drawn objects... that's what widgets do in 2d bitmapped space. Its been possible for some time (see GLUT) to implement a 2d interface, with widgets, etc, in OpenGL, which can be scaled just as easily, retains as much information, etc.
Really, I would have to say that for the Linux community, SGI's actions regarding OpenGL, and they're apparent attempts to pave the way for opensource OpenGL accelerated hardware drivers is more important. When we have hardware accelerated OpenGL drivers for most of the major cards, it would be relatively simple to create an OpenGL based WM, or OpenGL based apps, and get all the same abilities. The only realm that I know of where Postscript/PDF has a strong advantage over OpenGL is fonts, and considering the recent work done in integrating FreeType with OpenGL, I consider that an advantage likely to be shortlived.
As for the transparency effects, those are easy in OpenGL... but also here today in imlib2 and gdbpixbuf (actually, libart, I think).
When the Gnome guy said it was trivial, he was referring to AQUA, NOT QUARTZ!!! Aqua, i.e. dynamically scaling bitmaps through arbitrary transformations, and using transparency and truecolor widgets, is all possible today with libart and gdk-pixbuf, and possible tomorrow with hardware accelerated OpenGL.
I don't think Linux has much to worry about here.
(Speed and efficiency issues aside, which are currently being remedied. Most of the GNOME complaints earlier in the discussion can be laid at the feet of stacking libart, et. al., on top of imlib, which was designed and optimized for a different purpose. And OpenGL merely awaits hardware acceleration with capable drivers.)
KDevelop is looking nice... but much of what you are asking for (in terms of debugging, jumping to the error, editing, etc) is available for C,C++,Java,Perl,Python, etc, with one interface in the Data Display Debugger (DDD) at www.gnu.org/software/ddd.
View->Side Panel turned it off for me in M13 and M12.
Hasn't crashed for me yet. But I couldn't copy your message for the reply. Selected the text, looked at the edit menu, copy still grayed. Tried Ctrl-Insert and Ctrl-C, to no avail.
Let's face it, Perl and Python are (usually) mutually exclusive.:)
I have used Perl, Python, and PHP3 (no PHP4/Zend yet) extensively. I continue to use both. I use Python on several projects where I have to work with other individuals on the code.
So far, they seem to find it easier to understand my meaning in Python.
(I'm the sort of fellow who uses multiple pointer indirection in C/C++ w/o really thinking about it much... not good for most of the people I work with;-P)
When I have a quick script to write, I choose Python or Perl based on what is most readily to hand, as they seem nearly equal for this purpose. I do prefer Perl's documentation style. I like man-pages (though I seem to be very much alone in that), and find the regexp search features in less considerably easier that going to X for dvi, or lynx for html help for python. (html help is nice, but I can only search the current page, or use the limited search capacity provided by the website)
I've mostly used PHP3 when working with projects based in PHP3. IMP, TWIG, and PHPMYADMIN are all fun to work with. I implemented several complex MySQL based database interfaces with PHP3, rather than Zope, because it was easier to make the web-pages completely dynamic, using a single page to render subsets of columns from single tables, and multiple joins, with easy query's on whatever columns happened to be present.
When not constrained by other factors, I prefer to use Zope and DTML for my web-design, with Python as a backup to accomplish that which is beyond DTML.
The only thing which strongly pushes me from one ot the other, is if it seems to me that the project would be best implemented in an object fashion, because I don't like how Perl works with objects.
[ I do have to admit, I may not be the best example of a Perl vs. Python programmer, as I am also something of a language junkie. I have yet to use Postscript output extensively in a program, but I learned enough Postscript to write several PS programs to generate iterative and algorithmic images from our HP LJs. ]
The point of this rambling post, I guess, is merely to state that I am a single counterexample to his Ranger Rick's statement that Python and Perl are mutually exclusive. Of course, that means nothing, since he qualified it with 'usually', so I guess this means nothing at all!
This is a response to your comments about a 'database' based compilation system. The ReiserFS filesystem, which has been in the/. news lately due to its support for journaling, is designed for handling a multiplicity of small files/large directories efficiently. The FS creator, Hans Reiser, is trying to move the filesystem in the direction of being able to replace your 'database' without any loss of functionality or speed, and without sacrificing readability.
Check out his future plans on his site. Don't have URL handy, sorry.
I would hope, though I doubt it, that you would move away from Mandrake then. Mandrake's focus and goal is the addition of KDE to RedHat! If you're not even using X, why support Mandrake? If you want to get in and learn the system, why not try Debian/Slackware/Redhat?
>because to display the gif you would have to use >their algorithm.
This is just plain wrong. The Webserver NEVER uses the LZW scheme!! The browser receives the image STILL compressed, and then uncompresses it. They are trying to charge you even though you, as a web-hoster, may NEVER have used their algorithm! You don't have to use LZW to take a compressed GIF, download it from somewhere, and put it on your page... you only use LZW if YOU create or view the gif.
This scheme you lay out is not reasonable, because it involves people paying licensing fees while potentially never using the licensed technique.
However, if they use your GIF Proxy, then YOU, running the GIF Proxy, ARE using the LZW patent, and ARE liable.
So you take a situation where no liability actually exists, and create a situation where liability is present. I'm sure Unisys would love you for that.
Slashdot Mirror
Hmmm. Can't help but wonder if 'Foogle' might not have already done this with 'Foogle.' After all, what better way to flame freely, than to take 'Foogle.'. Since everybody knows that the groupies try to troll as someone by registering their nick with a period after it, which he reinforces by posting immediately after 'Foogle.'s comments "That wasn't me" signed 'Foogle', maybe he is 'Foogle.'.
That would be pretty sad though. Being one's own groupie, I mean. Then again, what about Hemos?
He was referring to Quartz to the extent that he could reproduce its ability to accomplish Aqua's look, including arbitrary transformations of screen elements, as I said.
This does NOT include true vectorization of complete interface elements, nor the ability for some degree of intelligence to reside in the display server by its use of Postscript ala NeWS, etc.
So I stand by my statement - We're talking about Aqua's look, not the full vectorization. Actually, Quartz throws out functionality. If an earlier poster was correct, PDF is NOT a strict superset of Postscript - the prior poster's claim was that PDF drops Turing-completeness. If so, then Quartz is dropping much of the power of NeWS, which is sad.
I favor Berlin, primarily because they seem to be trying for many of the goals of NeWS; specifically, the goal of the separation between the server and client being app-dependent.
Many of the complaints about X have to do with its network protocol; more specifically, the level at which it operates. Different applications work best at different levels of network abstraction. Berlin's design, based on Corba components, which can be either in the server or the client, allows each application to control which level of abstraction becomes the network layer. Thus, network traffic, even going through the overhead of the Corba protocol, can be minimized, because it may only take one Corba packet where X sends twenty.
But I'm moving off track - again, I'll state it - libart is NOT vector based - it is transformation based. It applies an arbitrary transformation matrix to a bitmapped image. This is not the same as using Postscript (which I have hand-written programs in --- not reports, not texts, PROGRAMS). Postscript is a Turing complete language with a rich graphics library built-in. IF PDF is not Turing-complete, that reduces the potential functionality of Quartz, but may enhance it in reality, since it means the interpreter and display paths can be more optimized. That has ever been the Mac Mantra, to sacrifice flexibility for ease, whether of implementation or use.
Libart provides optimized, fast, anti-aliased transformations of bitmapped images. (Note, my understanding of libart is largely from reading documents on GNOME website and Enlightenment website talking about imlib1 and imlib2, and why Gnome is moving away from imlib, etc. My understanding could be flawed.)
Actually, the concept of a vector based GUI is not new, considering they 'copied' it from NeXT (really cool stuff for its time), but irrespective of that, an Open-Source project to provide a vector-based alternative to X has been in progress for some time.
It currently suffers from the ESR RampUp syndrome - i.e. the necessity to have a minimally working product before the OS scale-up really begins to have an impact.
They are basing it on OpenGL and GGI. Its called 'Berlin'. They've got a page at SourceForge.
Nothing actually usable in terms of replacing X yet though.
Then there's always the GNUStep people... I think they're trying to use 'Display Ghostscript'.
All things considered, I don't think Quartz is a really monumental achievement. After all, they had NeXT's implementation of Display Postscript to work from. Considering how quickly gv was adapted to display PDF files, I don't think there was too much work involved in upping 'Display Postscript' to 'Display PDF'. And I think the dropping of the license fee from Postscript to PDF was probably the driving factor, moreso than the technical issues mentioned.
As for the ability to reference previously drawn objects... that's what widgets do in 2d bitmapped space. Its been possible for some time (see GLUT) to implement a 2d interface, with widgets, etc, in OpenGL, which can be scaled just as easily, retains as much information, etc.
Really, I would have to say that for the Linux community, SGI's actions regarding OpenGL, and they're apparent attempts to pave the way for opensource OpenGL accelerated hardware drivers is more important. When we have hardware accelerated OpenGL drivers for most of the major cards, it would be relatively simple to create an OpenGL based WM, or OpenGL based apps, and get all the same abilities. The only realm that I know of where Postscript/PDF has a strong advantage over OpenGL is fonts, and considering the recent work done in integrating FreeType with OpenGL, I consider that an advantage likely to be shortlived.
As for the transparency effects, those are easy in OpenGL... but also here today in imlib2 and gdbpixbuf (actually, libart, I think).
When the Gnome guy said it was trivial, he was referring to AQUA, NOT QUARTZ!!! Aqua, i.e. dynamically scaling bitmaps through arbitrary transformations, and using transparency and truecolor widgets, is all possible today with libart and gdk-pixbuf, and possible tomorrow with hardware accelerated OpenGL.
I don't think Linux has much to worry about here.
(Speed and efficiency issues aside, which are currently being remedied. Most of the GNOME complaints earlier in the discussion can be laid at the feet of stacking libart, et. al., on top of imlib, which was designed and optimized for a different purpose. And OpenGL merely awaits hardware acceleration with capable drivers.)
KDevelop is looking nice... but much of what you are asking for (in terms of debugging, jumping to the error, editing, etc) is available for C,C++,Java,Perl,Python, etc, with one interface in the Data Display Debugger (DDD) at www.gnu.org/software/ddd.
Very cool piece of software.
View->Side Panel turned it off for me in M13 and M12.
Hasn't crashed for me yet. But I couldn't copy your message for the reply. Selected the text, looked at the edit menu, copy still grayed. Tried Ctrl-Insert and Ctrl-C, to no avail.
I too am posting with M13.
Let's face it, Perl and Python are (usually) mutually exclusive. :)
;-P)
I have used Perl, Python, and PHP3 (no PHP4/Zend yet) extensively. I continue to use both. I use Python on several projects where I have to work with other individuals on the code.
So far, they seem to find it easier to understand my meaning in Python.
(I'm the sort of fellow who uses multiple pointer indirection in C/C++ w/o really thinking about it much... not good for most of the people I work with
When I have a quick script to write, I choose Python or Perl based on what is most readily to hand, as they seem nearly equal for this purpose. I do prefer Perl's documentation style. I like man-pages (though I seem to be very much alone in that), and find the regexp search features in less considerably easier that going to X for dvi, or lynx for html help for python. (html help is nice, but I can only search the current page, or use the limited search capacity provided by the website)
I've mostly used PHP3 when working with projects based in PHP3. IMP, TWIG, and PHPMYADMIN are all fun to work with. I implemented several complex MySQL based database interfaces with PHP3, rather than Zope, because it was easier to make the web-pages completely dynamic, using a single page to render subsets of columns from single tables, and multiple joins, with easy query's on whatever columns happened to be present.
When not constrained by other factors, I prefer to use Zope and DTML for my web-design, with Python as a backup to accomplish that which is beyond DTML.
The only thing which strongly pushes me from one ot the other, is if it seems to me that the project would be best implemented in an object fashion, because I don't like how Perl works with objects.
[ I do have to admit, I may not be the best example of a Perl vs. Python programmer, as I am also something of a language junkie. I have yet to use Postscript output extensively in a program, but I learned enough Postscript to write several PS programs to generate iterative and algorithmic images from our HP LJs. ]
The point of this rambling post, I guess, is merely to state that I am a single counterexample to his Ranger Rick's statement that Python and Perl are mutually exclusive. Of course, that means nothing, since he qualified it with 'usually', so I guess this means nothing at all!
Oh well.
This is a response to your comments about a 'database' based compilation system. The ReiserFS filesystem, which has been in the /. news lately due to its support for journaling, is designed for handling a multiplicity of small files/large directories efficiently. The FS creator, Hans Reiser, is trying to move the filesystem in the direction of being able to replace your 'database' without any loss of functionality or speed, and without sacrificing readability.
Check out his future plans on his site. Don't have URL handy, sorry.
I would hope, though I doubt it, that you would move away from Mandrake then. Mandrake's focus and goal is the addition of KDE to RedHat! If you're not even using X, why support Mandrake? If you want to get in and learn the system, why not try Debian/Slackware/Redhat?
>because to display the gif you would have to use
>their algorithm.
This is just plain wrong. The Webserver NEVER uses the LZW scheme!! The browser receives the image STILL compressed, and then uncompresses it. They are trying to charge you even though you, as a web-hoster, may NEVER have used their algorithm! You don't have to use LZW to take a compressed GIF, download it from somewhere, and put it on your page... you only use LZW if YOU create or view the gif.
This scheme you lay out is not reasonable, because it involves people paying licensing fees while potentially never using the licensed technique.
However, if they use your GIF Proxy, then YOU, running the GIF Proxy, ARE using the LZW patent, and ARE liable.
So you take a situation where no liability actually exists, and create a situation where liability is present. I'm sure Unisys would love you for that.