It is true that hardly any GNOME applications use Bonobo. Its use is limited to Nautilus, AbiWord, and Gnumeric as far as I can tell. The Network Object Model was supposed to be a fundemental part of GNOME, but they really dropped the ball with it.
You see, Bonobo is based on CORBA. And CORBA, as I can tell you from working on a fairly large project using it, is a total piece of crap. Its a design-by-committe API that has no semblence of order, and requires a thousand page manual to describe a fundementally simple concept. Oh sure, CORBA is great in theory. Its platform independent, network transparent, feature-packed, well-supported by the industry, and with a good ORB (OmniORB or ORBit) can be quite fast. Its also an absolute bitch to program, and the API (especially the C++ one) is more horrid than even MFC!
When the component models of GNOME and KDE were being designed, I remember the debate between using CORBA and making something new. The GNOME people went with CORBA and stuck to it. The KDE people tried a CORBA-based system (OpenParts) realized how badly it sucked, and ultimately rolled their own (KParts). The GNOME people ridiculed them for going that route (reinventing the wheel, they said). Well, it is now 2004, and KParts is a phenomenal success on KDE, thanks to its simplicity and power. Meanwhile, Bonobo is pretty much marginal on the GNOME platform, even according to original creator.
I find it always funny that KDE supporters always list re-use of existing libraries as a big minus point of Gnome, as if it is a bad thing to re-use and adopt none-Gnome supporting libraries, --- It is at once a strength and a weakness. By reusing existing libraries, they gain interoperation and speed up development. However, at the same time, they give up any semblence of a highly architectured, well-integrated platform. KDE has an extremely high level of integration and consistency precisely because the KDE project has an habit of making sure that anything that goes into KDE fits naturally into the desktop. One of GNOME's principle weaknesses is that its usage of external libraries tends to destroy integration within the desktop. In KDE, pretty much everything uses the same text-editing component. You write a text-editor KPart, and it'll work in KMail, KWrite, Kate, KDevelop, etc. In GNOME, pretty much everything uses a different text-editing component. When the Kvim KPart was developed, all of the above mentioned apps automatically got support for editing text with Vim. When Evolution got vim mail-editing support, gedit and anjuta didn't automatically get it. When GNOME's HIG adopted a new Okay/Cancel button order, apps had to change their code to adopt to the new format. In KDE, if the developers wanted to change the button order, they'd change a single line of code in a library!
Now do you think that at KDE they will be glad to get such technology? Oh sure they will take it and probably "adapt" it (like the Borg that is) --- That really doesn't make a whole lot of sense. Most of Project Utopia is desktop agnostic. Its like the Linux kernel, or glibc. KDE will "adapt it" as much as they "adapt" any other low-level API. They'll write a KDE wrapper for it and be done with it. (Without the KDE wrapper, it'd be C code, and C++ programmers don't want to use C libraries any more than C programmers want to use C++ libraries.) I don't really understand what's so borg-like about using APIs that were meant to be used in the first place?
into there desktop, but for sure the work they will put into it will only benefit KDE --- Its hardly KDE's fault. They are building a well-integrated platform. They make extensive use of code-sharing because that is good software design, not because of some political reason. Anybody is free to use KDE's technologies, just as much as one is free to use GNOME's technologies. If people don't want to use C++ code, or depend on Qt, that's really their problem. I mean, the GNOME project seems to have no problems spreading the glib dependency all over the place.
Project Utopia --- Most of this project (udev, hotplug, d-bus, HAL, etc) is not under the GNOME umbrella.
GTK+ --- Qt is there, and has the same number of dependencies as GTK+. And its GPL to boot. What's the problem here?
Freedesktop.org --------- Freedesktop.org is *not* a GNOME project. None of the freedesktop.org software projects are related to GNOME. Enchant is the closest, because it comes from AbiWord, which has a GNOME version... Hell, KDE has more representation on freedesktop.org than GNOME does, because D-BUS is directly modeled on DCOP, and is a key component for freedesktop.org.
Gstreamer --- Again, not a GNOME project. It uses glib, but then again, so does aRts! What gives people the idea that these things are GNOME projects?
ATK, Pango --- These *are* GNOME-related projects, though Pango is more GTK+ related than GNOME-related.
other projects (Xfree86, XFCE4, etc) without making everything it touches Gnome --- The GNOME project seems to have a tendency to push the idea that all the software it "adopts" is related to GNOME. Key example: many people now think that OpenOffice is a GNOME app, because it is part of "GNOME Office." Its absolutely ridiculous!
one big API --- KDE actually has a highly modular API. Try developing for it sometime. Its very complete and very consistent, but that doesn't mean
I hate to break it to you, but in Java, everything except primitives is accessed via a pointer. Sometimes, even a via a double-pointer (pointer-to-pointer) depending on the VM.
Actually, the Playstation 2 has a lot of RAM bandwidth. 3.2GB/sec of memory bandwidth from a 32-bit RDRAM setup. That is quite a lot considering that the system was released more than four years ago.
The decode bandwidth is a single x86 instruction per clock, but that's not a huge problem because of the trace cache. The issue bandwidth is three u-Ops per cycle, but this isn't a huge limitation because the P4 is a relatively narrow architecture. Its only got two ALUs and two FPUs compared to an Athlons three ALUs and three FPUs.
P4s aren't designed for efficiency, but raw performance. The long pipeline is an engineering decision. Consider, what market really pushes CPU performance? In the consumer arena, its games and media applications. They are "streaming" (predictable branching) type applications, and the pipeline latency has a lower cost than the benefit of the higher clock-speed.
So comparing a 2.0GHz Opteron to a 2.4GHz Xeon is not a fair comparison. You have to do a price/performance comparison. A 2.0GHz Opteron costs $700. A 2.4GHz Xeon costs $200. A 3.0GHz Xeon will be more comparable to the 2.0GHz Opteron and costs about $500. The Opteron is faster than the fastest Xeon, but on a price/performance standpoint, the Xeon is still competitive.
SSE does standard IEEE754 signel or double precision math. The Pentium 4's SSE2 unit (actually its FPU, but thats a detail) can handle 4 single-precision or 2 double-precision operations per cycle.
You should try it. The P4's x87 FPUs are phenomenally weak, much moreso than the P6-era CPUs. And memory latency and bandwidth aren't a huge problem, because the P4 has one of the fastest single-processor memory busses you can find. 6.4GB/sec is nothing to sneeze at!
Apparently, neither is anybody else from GaTech. If any other Tech students are reading this, I say we must redouble our efforts to get on this list! It'd be a shame to let all that perfectly good bandwidth go to waste!
Most modern Linux installers are easier than the WinNT installer. Instead of an intimidating partition screen, they have a simple button that says "partition automatically." They setup networking automatically, instead of bringing up a network settings dialog. Best of all, they have sane defaults, and copious explanatory text.
If Longhorn has pretty graphics and nice HTML with "what the fuck does this do" buttons, then it'll be as good as the SuSE installer, which already has these!
Not really feature-creep --- the option is only available by editing a text file. Also, it was a really disconcerting problem. On a fuzzy CRT, the missing corner pixels made things appear smoother, but on a high-res LCD, they just looked strange.
I like Konq better than Epiphany (Mozilla is not GNOME app, the GNOME project's PR aside) though Epiphany does have better rendering courtesy of Gecko. However, the gap is quickly narrowing, thanks partially to Safari's rendering fixes.
AbiWord and Gnumeric are great apps, but KOffice (the 1.3RC) is pretty competitive. And OpenOffice is to be KDE-ified in 2.x as well. That's the whole point of the NWF --- toolkit independent OpenOffice.
I'd say that Kopete is better than Gaim. Its got much better integration with KDE than Gaim has with GNOME. The only feature that's really missing is reliable AIM file-transfer.
The GIMP is not a GNOME app (as its developers repeatedly keep saying) so its irrelevent. Its UI is completely alien to both GNOME and KDE, so GIMP with the GTK-Qt theme is about as good as GIMP inside GNOME.
And don't forget about Quanta, the best graphical HTML editor on Linux, as well as Kate, which is a much better programmer's editor than GEdit.
In 3.2, Kontact should also give Evolution a run for its money. KMail in 3.2 has been getting a lot of very positive reviews.
Erm. KDE/Qt isn't any more monolithic than GNOME/GTK+. All the stuff that GNOME has as completely seperate libraries (libxml, etc) are seperate modules of Qt. In Qt4, Qt will become even more modularized. And KDE is completely component-based. KHTML is just a component somewhere that any application can use. Contrast that to GNOME's browser, Epiphany, that doesn't use Bonobo to embed Gecko.
KDE's development style is probably more monolithic than GNOME's, but the code is highly modular.
Actually, on any distro with a good package manager, it is that easy. You start up the package manager (Synaptic or whatever) and click the upgrade button. Konstruct is just for those who want KDE right *now* instead of waiting a week for packagers to release binaries.
Heh. I remember once that I complained on an OSNews or Slashdot post about disliking the dotNET style's missing corner pixels. C.Lee read it and posted a reply saying he'd added an option to enable square corners! These guys are *seriously* dedicated, and props to all of them:)
Probably a bit better, but don't forget that Qt is already based on a very dynamic message-based system (signals and slots) so it wouldn't be as big a win as you'd think.
What is retarded is your belief that you, as an EE, are of a higher order of magnitude than that of a Ph.D. professor. -------- I'm not an EE, nor am I the original poster.
I will state this now and at the end of my post...You took my comment out of context for your own benefit. ------- No I didn't.
Without Physics and Mathematics, what is EE? Nothing. The same goes for Chemistry. They are both applied Physics fields. --------- While true, that doesn't mean that a physicist necessarily knows jack-shit about chemistry or electrical engineering. We were talking about audio signals, and I am more inclined to take the word of an EE than a physicist, regardless of the taxonomy of the fields. The EE works directly with this sort of thing, while the physicist only understands it indirectly, unless he is a specialist.
She probably was wondering what the hell this "Rumbus RAM" was, since the box listed "Rambus RAM" and concluded tahat you didn't have the foggiest clue what you were talking about:)
I think you parsed that sentence wrong. He implied that men do get all glassy eyed and impressionable over shiny things. Slashdot is entirely consistent with this conjecture.
EE is simply a field of applied Physics. An EE is an order of magnitude lower on the food chain than a Physics professor. --------- That's a retarded comment. That's like saying that a physicist is a better authority on chemical processes, because chemistry is just a byproduct of quantum physics. The EE spends a whole lot more time studying the material concerning filters and audio signals, and its not a strech to believe that he'd be more informed about the subject than a physicist, unless the latter happened to specialize in electric signals.
Slashdot Mirror
Explain this then.
And this.
And this.
It is true that hardly any GNOME applications use Bonobo. Its use is limited to Nautilus, AbiWord, and Gnumeric as far as I can tell. The Network Object Model was supposed to be a fundemental part of GNOME, but they really dropped the ball with it.
You see, Bonobo is based on CORBA. And CORBA, as I can tell you from working on a fairly large project using it, is a total piece of crap. Its a design-by-committe API that has no semblence of order, and requires a thousand page manual to describe a fundementally simple concept. Oh sure, CORBA is great in theory. Its platform independent, network transparent, feature-packed, well-supported by the industry, and with a good ORB (OmniORB or ORBit) can be quite fast. Its also an absolute bitch to program, and the API (especially the C++ one) is more horrid than even MFC!
When the component models of GNOME and KDE were being designed, I remember the debate between using CORBA and making something new. The GNOME people went with CORBA and stuck to it. The KDE people tried a CORBA-based system (OpenParts) realized how badly it sucked, and ultimately rolled their own (KParts). The GNOME people ridiculed them for going that route (reinventing the wheel, they said). Well, it is now 2004, and KParts is a phenomenal success on KDE, thanks to its simplicity and power. Meanwhile, Bonobo is pretty much marginal on the GNOME platform, even according to original creator.
I find it always funny that KDE supporters always list re-use of existing libraries as a big minus point of Gnome, as if it is a bad thing to re-use and adopt none-Gnome supporting libraries,
---
It is at once a strength and a weakness. By reusing existing libraries, they gain interoperation and speed up development. However, at the same time, they give up any semblence of a highly architectured, well-integrated platform. KDE has an extremely high level of integration and consistency precisely because the KDE project has an habit of making sure that anything that goes into KDE fits naturally into the desktop. One of GNOME's principle weaknesses is that its usage of external libraries tends to destroy integration within the desktop. In KDE, pretty much everything uses the same text-editing component. You write a text-editor KPart, and it'll work in KMail, KWrite, Kate, KDevelop, etc. In GNOME, pretty much everything uses a different text-editing component. When the Kvim KPart was developed, all of the above mentioned apps automatically got support for editing text with Vim. When Evolution got vim mail-editing support, gedit and anjuta didn't automatically get it. When GNOME's HIG adopted a new Okay/Cancel button order, apps had to change their code to adopt to the new format. In KDE, if the developers wanted to change the button order, they'd change a single line of code in a library!
Now do you think that at KDE they will be glad to get such technology? Oh sure they will take it and probably "adapt" it (like the Borg that is)
---
That really doesn't make a whole lot of sense. Most of Project Utopia is desktop agnostic. Its like the Linux kernel, or glibc. KDE will "adapt it" as much as they "adapt" any other low-level API. They'll write a KDE wrapper for it and be done with it. (Without the KDE wrapper, it'd be C code, and C++ programmers don't want to use C libraries any more than C programmers want to use C++ libraries.) I don't really understand what's so borg-like about using APIs that were meant to be used in the first place?
into there desktop, but for sure the work they will put into it will only benefit KDE
---
Its hardly KDE's fault. They are building a well-integrated platform. They make extensive use of code-sharing because that is good software design, not because of some political reason. Anybody is free to use KDE's technologies, just as much as one is free to use GNOME's technologies. If people don't want to use C++ code, or depend on Qt, that's really their problem. I mean, the GNOME project seems to have no problems spreading the glib dependency all over the place.
Project Utopia
---
Most of this project (udev, hotplug, d-bus, HAL, etc) is not under the GNOME umbrella.
GTK+
---
Qt is there, and has the same number of dependencies as GTK+. And its GPL to boot. What's the problem here?
Freedesktop.org
---------
Freedesktop.org is *not* a GNOME project. None of the freedesktop.org software projects are related to GNOME. Enchant is the closest, because it comes from AbiWord, which has a GNOME version... Hell, KDE has more representation on freedesktop.org than GNOME does, because D-BUS is directly modeled on DCOP, and is a key component for freedesktop.org.
Gstreamer
---
Again, not a GNOME project. It uses glib, but then again, so does aRts! What gives people the idea that these things are GNOME projects?
ATK, Pango
---
These *are* GNOME-related projects, though Pango is more GTK+ related than GNOME-related.
other projects (Xfree86, XFCE4, etc) without making everything it touches Gnome
---
The GNOME project seems to have a tendency to push the idea that all the software it "adopts" is related to GNOME. Key example: many people now think that OpenOffice is a GNOME app, because it is part of "GNOME Office." Its absolutely ridiculous!
one big API
---
KDE actually has a highly modular API. Try developing for it sometime. Its very complete and very consistent, but that doesn't mean
I hate to break it to you, but in Java, everything except primitives is accessed via a pointer. Sometimes, even a via a double-pointer (pointer-to-pointer) depending on the VM.
Actually, the Playstation 2 has a lot of RAM bandwidth. 3.2GB/sec of memory bandwidth from a 32-bit RDRAM setup. That is quite a lot considering that the system was released more than four years ago.
That blows. There is so much cool stuff you can do with 64-bit pointers, because nobody really neads more than about 45 of those bits.
The decode bandwidth is a single x86 instruction per clock, but that's not a huge problem because of the trace cache. The issue bandwidth is three u-Ops per cycle, but this isn't a huge limitation because the P4 is a relatively narrow architecture. Its only got two ALUs and two FPUs compared to an Athlons three ALUs and three FPUs.
P4s aren't designed for efficiency, but raw performance. The long pipeline is an engineering decision. Consider, what market really pushes CPU performance? In the consumer arena, its games and media applications. They are "streaming" (predictable branching) type applications, and the pipeline latency has a lower cost than the benefit of the higher clock-speed.
So comparing a 2.0GHz Opteron to a 2.4GHz Xeon is not a fair comparison. You have to do a price/performance comparison. A 2.0GHz Opteron costs $700. A 2.4GHz Xeon costs $200. A 3.0GHz Xeon will be more comparable to the 2.0GHz Opteron and costs about $500. The Opteron is faster than the fastest Xeon, but on a price/performance standpoint, the Xeon is still competitive.
SSE does standard IEEE754 signel or double precision math. The Pentium 4's SSE2 unit (actually its FPU, but thats a detail) can handle 4 single-precision or 2 double-precision operations per cycle.
You should try it. The P4's x87 FPUs are phenomenally weak, much moreso than the P6-era CPUs. And memory latency and bandwidth aren't a huge problem, because the P4 has one of the fastest single-processor memory busses you can find. 6.4GB/sec is nothing to sneeze at!
Ha ha, I'm not on it :)
Apparently, neither is anybody else from GaTech. If any other Tech students are reading this, I say we must redouble our efforts to get on this list! It'd be a shame to let all that perfectly good bandwidth go to waste!
1 gigabit = 128MB. Quite significant for a hand-held, really.
Most modern Linux installers are easier than the WinNT installer. Instead of an intimidating partition screen, they have a simple button that says "partition automatically." They setup networking automatically, instead of bringing up a network settings dialog. Best of all, they have sane defaults, and copious explanatory text.
If Longhorn has pretty graphics and nice HTML with "what the fuck does this do" buttons, then it'll be as good as the SuSE installer, which already has these!
Not really feature-creep --- the option is only available by editing a text file. Also, it was a really disconcerting problem. On a fuzzy CRT, the missing corner pixels made things appear smoother, but on a high-res LCD, they just looked strange.
Why haven't Microsoft and Apple combined forces to create one hugely powerful desktop? It sounds just as silly as combining KDE and GNOME.
There is no such thing as the best of both worlds when the two desktops have completely different designs.
Well, it really depends.
I like Konq better than Epiphany (Mozilla is not GNOME app, the GNOME project's PR aside) though Epiphany does have better rendering courtesy of Gecko. However, the gap is quickly narrowing, thanks partially to Safari's rendering fixes.
AbiWord and Gnumeric are great apps, but KOffice (the 1.3RC) is pretty competitive. And OpenOffice is to be KDE-ified in 2.x as well. That's the whole point of the NWF --- toolkit independent OpenOffice.
I'd say that Kopete is better than Gaim. Its got much better integration with KDE than Gaim has with GNOME. The only feature that's really missing is reliable AIM file-transfer.
The GIMP is not a GNOME app (as its developers repeatedly keep saying) so its irrelevent. Its UI is completely alien to both GNOME and KDE, so GIMP with the GTK-Qt theme is about as good as GIMP inside GNOME.
And don't forget about Quanta, the best graphical HTML editor on Linux, as well as Kate, which is a much better programmer's editor than GEdit.
In 3.2, Kontact should also give Evolution a run for its money. KMail in 3.2 has been getting a lot of very positive reviews.
Erm. KDE/Qt isn't any more monolithic than GNOME/GTK+. All the stuff that GNOME has as completely seperate libraries (libxml, etc) are seperate modules of Qt. In Qt4, Qt will become even more modularized. And KDE is completely component-based. KHTML is just a component somewhere that any application can use. Contrast that to GNOME's browser, Epiphany, that doesn't use Bonobo to embed Gecko.
KDE's development style is probably more monolithic than GNOME's, but the code is highly modular.
Actually, on any distro with a good package manager, it is that easy. You start up the package manager (Synaptic or whatever) and click the upgrade button. Konstruct is just for those who want KDE right *now* instead of waiting a week for packagers to release binaries.
:)
Think of it as 0-day KDE warez
Heh. I remember once that I complained on an OSNews or Slashdot post about disliking the dotNET style's missing corner pixels. C.Lee read it and posted a reply saying he'd added an option to enable square corners! These guys are *seriously* dedicated, and props to all of them :)
Probably a bit better, but don't forget that Qt is already based on a very dynamic message-based system (signals and slots) so it wouldn't be as big a win as you'd think.
Math is hard?
US pop = 300m
World pop = 6 billion
So its about 20 times, not 2000.
What is retarded is your belief that you, as an EE, are of a higher order of magnitude than that of a Ph.D. professor.
--------
I'm not an EE, nor am I the original poster.
I will state this now and at the end of my post...You took my comment out of context for your own benefit.
-------
No I didn't.
Without Physics and Mathematics, what is EE? Nothing. The same goes for Chemistry. They are both applied Physics fields.
---------
While true, that doesn't mean that a physicist necessarily knows jack-shit about chemistry or electrical engineering. We were talking about audio signals, and I am more inclined to take the word of an EE than a physicist, regardless of the taxonomy of the fields. The EE works directly with this sort of thing, while the physicist only understands it indirectly, unless he is a specialist.
She probably was wondering what the hell this "Rumbus RAM" was, since the box listed "Rambus RAM" and concluded tahat you didn't have the foggiest clue what you were talking about :)
I think you parsed that sentence wrong. He implied that men do get all glassy eyed and impressionable over shiny things. Slashdot is entirely consistent with this conjecture.
EE is simply a field of applied Physics. An EE is an order of magnitude lower on the food chain than a Physics professor.
---------
That's a retarded comment. That's like saying that a physicist is a better authority on chemical processes, because chemistry is just a byproduct of quantum physics. The EE spends a whole lot more time studying the material concerning filters and audio signals, and its not a strech to believe that he'd be more informed about the subject than a physicist, unless the latter happened to specialize in electric signals.