That would make no sense. Why would TT is an employee owned company. The employees would have to approve any merger. Why the hell would they merge with a sinking ship (SCO) for a measly 5.7% stake? Hell, a lot of companies that Canopy group invests in have absolutely no relation to SCO. They invest in a company (LinuxNetworx) that builds Linux-based clusters! You think they're going to make LLNL (one of their customers) pay a $700 Linux license fee for each node they build???
Hint: Look at Canopy's website. Note that TT is listed under "Portfolio Companies." Understand that this in no way means that they are controlled by Canopy group. Hell, Microsoft owned about as much of Apple after their $150 million investment. Did that make Apple a Microsoft puppet?
WTF? He asked for Qt apps. Why are you listing GTK apps?
Re:I use linux but IANALH (I am not a linux hacker
on
What to Expect From Qt 4
·
· Score: 2, Interesting
Qt4 will definately help in some ways. In particular, the fact that all widgets will now be double-buffered (instead of just most of the widgets) means that a lot of tearing will go away. Startup time should be reduced a little bit as well. Hopefully, a lot of work will go into fixing synchronization issues, which is the real problem holding back X-based GUIs.
KDE itself is getting much better. I'm using a CVS version of KDE, and can say that things are *much* faster. Konqueror starts instantly, and most apps start in less than 2 seconds. Konqueror has zero rubber-banding when resizing medium-complexity websites, and hardly noticible rubber-banding when doing reflow-heavy sites like Slashdot. The KOffice apps are all very fast, none exhibit any rubber-banding at all and all start up in a couple of seconds. All the standard widgets are really fast --- Juk for example, resizes with zero redraw even with a 2000-item listview. The only apps that really need work are those that use custom views or widgets (like Konqueror).
My setup is KDE CVS from Aug. 8, 2003. I'm Gentoo 1.4 on a 2GHz P4.
Look at it this way. If library v2.0 is so much better than library v1.0, most of that code is going to be redundent. Adding all the features of library v2.0 while still keeping compatibility with library v1.0 means that you'll get almost the same memory usage as having both 2.0 and 1.0 installed at the same time. At least with the split-up version, the users have the choice of only keeping the apps that use a particular version of the library.
Oh, please. Just take one look at the "generic list" code in the Linux kernel and tell me that it wouldn't have been better if they'd just used templates instead! Or take a look at the driver API and tell me if it wouldn't have been better if they'd just used an abstract base class. Take a look at any code that handles strings and tell me std::string isn't a much better solution. C++ isn't a great language for a lot of things (I too, just use Python when I don't need the speed) but it makes a damn-fine systems programming language.
WTF? The guy simply mentioned what distro he was using, which was different from SuSE. He never brought FreeBSD into the comparison! You have no idea why he is using Gentoo rather than something else. Personally (as someone who has used both) I use Gentoo because its software library is updated quicker, and certain Linux subsystems (ALSA, preemptive scheduler, new I/O scheduler) are better for desktop use than the FreeBSD equivilients.
This isn't something like a typo or grammer mistake. This is a huge exaggeration verging on blatent lie.
A) The compositing time is not a huge part of the overall process, and more importantly, other systems do not have the overhead of doing this compositing. Saying that QE accelerates "graphics" (which is what Apple's marketing drivel says) is akin to a car manufacturer touting tuned spark-plug timings as a major new feature.
B) Apple makes a reference to Microsoft's Longhorn technology in its QE website. Longhorn is true 3D acceleration for graphics, which accelerates actual drawing. The two aren't remotely comparable.
C) Obviously, there is something misleading about Apple's marketing. Every time an article about *real* hardware accelerated desktops comes up, people like you come up and mention Quartz Extreme!
A) I'm pissed because Apple makes it out to be so much more than it is. Its not only not an optimal solution, its not even a solution to the rendering problem. Its a solution to the compositing problem, but not hyped as such.
B) I'm going by your statement: "But it still does accellerate the time that matters."
I interpret that as, "it accelerates the important part." The important part is the rendering, not the compositing. Rendering is useful for real progress in GUIs. Compositing just makes those transparent, shadowed windows possible.
Not really. Most windowing systems use hardware blitters to accelerate moving window buffers to the screen, so they get that benifet too. Its just that Quartz requires that the blitter to alpha-blended window compositing, which can only be done via OpenGL. It does speed things up relative to non-accelerated Quartz, but not relative to other window systems. The real promise of HW-accelerated vector graphics is that it enables you to make very visually complex applications. A more sophisticated drawing system that accelerated drawing with OpenGL too would give you this, but Quartz won't.
Because LISP does it, so it must be right? >>>>>>>>> I'm not even a Lisp programmer! I'm a C++ programmer. But its so obvious, once you are exposed to it, that its not even funny.
Data as code violates the principle of least power and leaves you wide open to doing things in "data" that are very nasty. >>>>>>>>> It's not appropriate in all cases, but is in most. If HTML was code, we wouldn't have all of this machinery (XSLT, CSS, DHTML, etc) to make it behave like code.
And while it may violate the principle of least powers, that's not a crime in and of itself. What matters is whether the end product is secure. Remember, more code = more bugs. Its far easier to build a totally secure sandbox for a VM with a few dozen instructions, than to make sure that dozens of different ad-hoc interpreters are free of buffer overflows and potential exploits.
There is no good reason for it. >>>>>>>>> Oh yes there is. Just take a look at the cross platform build scripts for the Linux kernel or KDE. QT had to make a tool (qmake) just to make the mess managable. Now, take a look at how f*cking easy SCONS makes building. Programmable data is the future. Just take a look at graphics cards. Static data (textures, geometry) was too limiting, so they needed to make the cards programmable (shaders). Static HTML was too limiting, so they needed to make the web programmable (Flash, XSLT, PHP, CGI, etc). Its far better to pick some programmable data representations and work on making them secure, than to keep writing and rewriting bug-ridden, exploitable processors for an ever growing set of static data representations.
Now you've effectively tied your system to a single language. >>>>>>> Now, there, what exactly do you think make is? If you answered "one-off, extremely limiting, non-standard programming language" you get a cookie! I knew I was heading down the wrong path when I found myself writing stuff like:
module-win32.cpp
Now I have to write an interpreter for my own god-damn one-off language!
As for interfacing to other languages, consider this: which is easier? Using Python's excellent's inter-language interfacing capabilities to have Python code directly interact with a program written in another language, or writing (and maintaining!) a (verbose!) set of XML data files and writing an interpreter for our very own XML-based programming language?
While Lisp programmers can be scary* there is some element of truth to it. I was trying to extend SCONS (a build system) to make it easier to use while building my OS kernel. I needed to have lots of conditionals, to handle varying platforms and build situations. Now that I look back on it, there are a lot of Lisp ideas in there. Specifically, if code is data, then data should be code, right? So I ditched my original idea of using an XML file format, and decided to use regular python scripts as the config files. It worked like a charm, and the resulting build system was flexible enough that when I applied it to a later project for work, I only had to write a couple of dozen lines of build scripts for a complicated project that needed to build on Linux, Windows, be configurable to use various CORBA ORBs, and have switchable drivers at compile time.
More and more, I'm thinking corporate America is decades behind what the academic world takes for granted. XSLT, for example, is something that never should have happened. And its not just Lisp. Take, for example, DAML+OIL. Its an XML-based language that can make statements in first order logic that can be verified by a theorem prover. Its so complicated and verbose, that its nearly impossible to write by hand, and most people use GUI tools to work wih it. In the next version, they're adding support for limited execution capability (ala XSLT). Meanwhile, I'm thinking, "hello --- Haskell?"
*> My impression of this mainly comes from comp.lang.lisp. I find some of the people who hang out there to be among the rudest I've seen on the Internet. Some pricks, like Eric Naggum (search for "arrogant" on c.l.c in Google Groups and see who gets the first 20 hits...) are actually revered for their rudeness! It might just be there are more math/pure-science types on that board, and while they're definately smart, they can also be rather rude.
The RenderAccel support in the NVIDIA drivers is not complete. That's why its disabled by default. From the benchmark results, it seems that Render wins when there is no scaling involved, and loses badly when there is scaling involved. This suggest an obvious answer --- scaling is not accelerated on the Render implementation on NVIDIA cards! As a result, when scaling is used, the card falls back on a software implementation that is obviously not as good as imlib2's very optimized software implementation. Now, why would NVIDIA bother with Render support if no scaling can be used? Because the only real user of Render at the moment is Xft, which uses it to composit AA text! Of course, the glyph bitmaps are not scaled, because that would reduce sharpness. So NVIDIA released a half-assed Render implementation (they do not, to be fair, that its incomplete, and disable it by default) so the common case of AA-text would get a speed-up!
What? He was trying to use Render, a *graphics* API, to render *graphics* using hardware acceleration from the *graphics* card! He wasn't trying to run general purpose code.
Arg. Not again. -5 "dis"informative. Quartz "Extreme" does not accelerate any actual rendering! According to Apple's very on Siggraph presentation, all 2D rendering is still done via software. Only final window *compositing* (doing the alpha blend between all the windows) and window-level effects (like the genie effect) are done via OpenGL.
Actually, that might not be the case. Because glxgears is such a simple benchmark, it redraws ridiculously fast. As a result, you might get weird artifacts. Try a more complicated benchmark. Also, what kernel are you running? The 2.5 series is supposed to be much better for this sort of thing.
Doesn't happen with Debian, or with Gentoo. Packages make it into unstable and into Portage almost as soon (sometimes before!) they are released. The other distros will catch up eventually. Besides, consider how most Windows software works. They only release new versions once a year or two. The OSS philosophy is "release early, release often" but that doesn't mean you have to stay on the cutting edge of each release*. The distros do a degree of testing as well, so waiting for the distro packages to come out is much more in line with what users are used to in Windows.
When people say that they think a dual-licensed GUI toolkit is bad for the goals that open source software is trying to achieve >>>>>>>>> Whoa. Qt/X11 is *GPL*. What more do you want? LGPL'ing it will only be even further from the goals of the FSF. Its called the LesserGPL for a reason!
, or when they say that a C++-based toolkit won't do for them, that's not "bashing", that's an honest and straightforward assessment of their own needs. >>>>>>>>> Its also a rather suspect claim. There are very few reasons not to use C++ for GUI toolkits these days. In fact, most popular GUI toolkits (MFC, WTL, Qt, WxWindows, Fltk) on X11 are C++. The only ones that aren't are Motif (Lesstif) and GTK+.
This is the third time I've had to post this. Apps are not hard to install in Linux! The *vast* majority of these problems come from Linux users who try RedHat first, and Linux users who first go to the app's website to get packages.
1) If you use RedHat without Apt-4-RPM, don't even bother using Linux. Better yet, use SuSE (which has a good GUI package manager in the default install) or one of the Debian-based GUI distros. 2) Never download apps from the app's website. That's the Windows way, not the Linux way. Almost every significant app will have a package in your distro's package database. APT and Debian are better than the RPM distros in this regard (lots of RPMs, not too many keyed into Apt4RPM). To date, I've only run up against a handful of packages that weren't in the Portage database. Most of them (like d2c, the Dylan compiler) would not be installed by most users.
Slashdot Mirror
That would make no sense. Why would TT is an employee owned company. The employees would have to approve any merger. Why the hell would they merge with a sinking ship (SCO) for a measly 5.7% stake? Hell, a lot of companies that Canopy group invests in have absolutely no relation to SCO. They invest in a company (LinuxNetworx) that builds Linux-based clusters! You think they're going to make LLNL (one of their customers) pay a $700 Linux license fee for each node they build???
Dipshit.
A 5.7% stake hardly makes TT a "Canopy puppet."
Hint: Look at Canopy's website. Note that TT is listed under "Portfolio Companies." Understand that this in no way means that they are controlled by Canopy group. Hell, Microsoft owned about as much of Apple after their $150 million investment. Did that make Apple a Microsoft puppet?
WTF? He asked for Qt apps. Why are you listing GTK apps?
Qt4 will definately help in some ways. In particular, the fact that all widgets will now be double-buffered (instead of just most of the widgets) means that a lot of tearing will go away. Startup time should be reduced a little bit as well. Hopefully, a lot of work will go into fixing synchronization issues, which is the real problem holding back X-based GUIs.
KDE itself is getting much better. I'm using a CVS version of KDE, and can say that things are *much* faster. Konqueror starts instantly, and most apps start in less than 2 seconds. Konqueror has zero rubber-banding when resizing medium-complexity websites, and hardly noticible rubber-banding when doing reflow-heavy sites like Slashdot. The KOffice apps are all very fast, none exhibit any rubber-banding at all and all start up in a couple of seconds. All the standard widgets are really fast --- Juk for example, resizes with zero redraw even with a 2000-item listview. The only apps that really need work are those that use custom views or widgets (like Konqueror).
My setup is KDE CVS from Aug. 8, 2003. I'm Gentoo 1.4 on a 2GHz P4.
Look at it this way. If library v2.0 is so much better than library v1.0, most of that code is going to be redundent. Adding all the features of library v2.0 while still keeping compatibility with library v1.0 means that you'll get almost the same memory usage as having both 2.0 and 1.0 installed at the same time. At least with the split-up version, the users have the choice of only keeping the apps that use a particular version of the library.
The Pajeiro is Montero in the US too.
What McBride will be giving in jail.
</rimjob>
Oh, please. Just take one look at the "generic list" code in the Linux kernel and tell me that it wouldn't have been better if they'd just used templates instead! Or take a look at the driver API and tell me if it wouldn't have been better if they'd just used an abstract base class. Take a look at any code that handles strings and tell me std::string isn't a much better solution. C++ isn't a great language for a lot of things (I too, just use Python when I don't need the speed) but it makes a damn-fine systems programming language.
WTF? The guy simply mentioned what distro he was using, which was different from SuSE. He never brought FreeBSD into the comparison! You have no idea why he is using Gentoo rather than something else. Personally (as someone who has used both) I use Gentoo because its software library is updated quicker, and certain Linux subsystems (ALSA, preemptive scheduler, new I/O scheduler) are better for desktop use than the FreeBSD equivilients.
This isn't something like a typo or grammer mistake. This is a huge exaggeration verging on blatent lie.
A) The compositing time is not a huge part of the overall process, and more importantly, other systems do not have the overhead of doing this compositing. Saying that QE accelerates "graphics" (which is what Apple's marketing drivel says) is akin to a car manufacturer touting tuned spark-plug timings as a major new feature.
B) Apple makes a reference to Microsoft's Longhorn technology in its QE website. Longhorn is true 3D acceleration for graphics, which accelerates actual drawing. The two aren't remotely comparable.
C) Obviously, there is something misleading about Apple's marketing. Every time an article about *real* hardware accelerated desktops comes up, people like you come up and mention Quartz Extreme!
A) I'm pissed because Apple makes it out to be so much more than it is. Its not only not an optimal solution, its not even a solution to the rendering problem. Its a solution to the compositing problem, but not hyped as such.
B) I'm going by your statement: "But it still does accellerate the time that matters."
I interpret that as, "it accelerates the important part." The important part is the rendering, not the compositing. Rendering is useful for real progress in GUIs. Compositing just makes those transparent, shadowed windows possible.
Not really. Most windowing systems use hardware blitters to accelerate moving window buffers to the screen, so they get that benifet too. Its just that Quartz requires that the blitter to alpha-blended window compositing, which can only be done via OpenGL. It does speed things up relative to non-accelerated Quartz, but not relative to other window systems. The real promise of HW-accelerated vector graphics is that it enables you to make very visually complex applications. A more sophisticated drawing system that accelerated drawing with OpenGL too would give you this, but Quartz won't.
Because LISP does it, so it must be right?
>>>>>>>>>
I'm not even a Lisp programmer! I'm a C++ programmer. But its so obvious, once you are exposed to it, that its not even funny.
Data as code violates the principle of least power and leaves you wide open to doing things in "data" that are very nasty.
>>>>>>>>>
It's not appropriate in all cases, but is in most. If HTML was code, we wouldn't have all of this machinery (XSLT, CSS, DHTML, etc) to make it behave like code.
And while it may violate the principle of least powers, that's not a crime in and of itself. What matters is whether the end product is secure. Remember, more code = more bugs. Its far easier to build a totally secure sandbox for a VM with a few dozen instructions, than to make sure that dozens of different ad-hoc interpreters are free of buffer overflows and potential exploits.
There is no good reason for it.
>>>>>>>>>
Oh yes there is. Just take a look at the cross platform build scripts for the Linux kernel or KDE. QT had to make a tool (qmake) just to make the mess managable. Now, take a look at how f*cking easy SCONS makes building. Programmable data is the future. Just take a look at graphics cards. Static data (textures, geometry) was too limiting, so they needed to make the cards programmable (shaders). Static HTML was too limiting, so they needed to make the web programmable (Flash, XSLT, PHP, CGI, etc). Its far better to pick some programmable data representations and work on making them secure, than to keep writing and rewriting bug-ridden, exploitable processors for an ever growing set of static data representations.
Now you've effectively tied your system to a single language.
>>>>>>>
Now, there, what exactly do you think make is? If you answered "one-off, extremely limiting, non-standard programming language" you get a cookie! I knew I was heading down the wrong path when I found myself writing stuff like:
module-win32.cpp
Now I have to write an interpreter for my own god-damn one-off language!
As for interfacing to other languages, consider this: which is easier? Using Python's excellent's inter-language interfacing capabilities to have Python code directly interact with a program written in another language, or writing (and maintaining!) a (verbose!) set of XML data files and writing an interpreter for our very own XML-based programming language?
Not if they're ordinary french people. Eeks-ouvert (how it would be pronounced in French) is a perfectly sensible and nice sounding name.
While Lisp programmers can be scary* there is some element of truth to it. I was trying to extend SCONS (a build system) to make it easier to use while building my OS kernel. I needed to have lots of conditionals, to handle varying platforms and build situations. Now that I look back on it, there are a lot of Lisp ideas in there. Specifically, if code is data, then data should be code, right? So I ditched my original idea of using an XML file format, and decided to use regular python scripts as the config files. It worked like a charm, and the resulting build system was flexible enough that when I applied it to a later project for work, I only had to write a couple of dozen lines of build scripts for a complicated project that needed to build on Linux, Windows, be configurable to use various CORBA ORBs, and have switchable drivers at compile time.
More and more, I'm thinking corporate America is decades behind what the academic world takes for granted. XSLT, for example, is something that never should have happened. And its not just Lisp. Take, for example, DAML+OIL. Its an XML-based language that can make statements in first order logic that can be verified by a theorem prover. Its so complicated and verbose, that its nearly impossible to write by hand, and most people use GUI tools to work wih it. In the next version, they're adding support for limited execution capability (ala XSLT). Meanwhile, I'm thinking, "hello --- Haskell?"
*> My impression of this mainly comes from comp.lang.lisp. I find some of the people who hang out there to be among the rudest I've seen on the Internet. Some pricks, like Eric Naggum (search for "arrogant" on c.l.c in Google Groups and see who gets the first 20 hits...) are actually revered for their rudeness! It might just be there are more math/pure-science types on that board, and while they're definately smart, they can also be rather rude.
The RenderAccel support in the NVIDIA drivers is not complete. That's why its disabled by default. From the benchmark results, it seems that Render wins when there is no scaling involved, and loses badly when there is scaling involved. This suggest an obvious answer --- scaling is not accelerated on the Render implementation on NVIDIA cards! As a result, when scaling is used, the card falls back on a software implementation that is obviously not as good as imlib2's very optimized software implementation. Now, why would NVIDIA bother with Render support if no scaling can be used? Because the only real user of Render at the moment is Xft, which uses it to composit AA text! Of course, the glyph bitmaps are not scaled, because that would reduce sharpness. So NVIDIA released a half-assed Render implementation (they do not, to be fair, that its incomplete, and disable it by default) so the common case of AA-text would get a speed-up!
What? He was trying to use Render, a *graphics* API, to render *graphics* using hardware acceleration from the *graphics* card! He wasn't trying to run general purpose code.
Arg. Not again. -5 "dis"informative. Quartz "Extreme" does not accelerate any actual rendering! According to Apple's very on Siggraph presentation, all 2D rendering is still done via software. Only final window *compositing* (doing the alpha blend between all the windows) and window-level effects (like the genie effect) are done via OpenGL.
Actually, that might not be the case. Because glxgears is such a simple benchmark, it redraws ridiculously fast. As a result, you might get weird artifacts. Try a more complicated benchmark. Also, what kernel are you running? The 2.5 series is supposed to be much better for this sort of thing.
Who is Lawrence Rosen? The love-child of Lawrence Lessig and Hillary Rosen.
That sound you just heard was the heads of every single slashdotter simultaniously exploding...
People cheerleader Google because they're not forced to use it, but its so good they do anway.
People bitch about Microsoft because they're forced to use it, even though its so bad that they don't want to.
Doesn't happen with Debian, or with Gentoo. Packages make it into unstable and into Portage almost as soon (sometimes before!) they are released. The other distros will catch up eventually. Besides, consider how most Windows software works. They only release new versions once a year or two. The OSS philosophy is "release early, release often" but that doesn't mean you have to stay on the cutting edge of each release*. The distros do a degree of testing as well, so waiting for the distro packages to come out is much more in line with what users are used to in Windows.
*> This coming from the guy who runs KDE CVS...
When people say that they think a dual-licensed GUI toolkit is bad for the goals that open source software is trying to achieve
>>>>>>>>>
Whoa. Qt/X11 is *GPL*. What more do you want? LGPL'ing it will only be even further from the goals of the FSF. Its called the LesserGPL for a reason!
, or when they say that a C++-based toolkit won't do for them, that's not "bashing", that's an honest and straightforward assessment of their own needs.
>>>>>>>>>
Its also a rather suspect claim. There are very few reasons not to use C++ for GUI toolkits these days. In fact, most popular GUI toolkits (MFC, WTL, Qt, WxWindows, Fltk) on X11 are C++. The only ones that aren't are Motif (Lesstif) and GTK+.
Qt/X11 is Free Software. In fact, its freer (according to the FSF) than GTK+, which uses the *Lesser* GPL.
This is the third time I've had to post this. Apps are not hard to install in Linux! The *vast* majority of these problems come from Linux users who try RedHat first, and Linux users who first go to the app's website to get packages.
1) If you use RedHat without Apt-4-RPM, don't even bother using Linux. Better yet, use SuSE (which has a good GUI package manager in the default install) or one of the Debian-based GUI distros.
2) Never download apps from the app's website. That's the Windows way, not the Linux way. Almost every significant app will have a package in your distro's package database. APT and Debian are better than the RPM distros in this regard (lots of RPMs, not too many keyed into Apt4RPM). To date, I've only run up against a handful of packages that weren't in the Portage database. Most of them (like d2c, the Dylan compiler) would not be installed by most users.